Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Using public variables - and losing public variables

Status
Not open for further replies.

nodrog77

Programmer
Sep 26, 2007
47
AU
Hi all,

I've been trying to use some public variables in my DB but they seem to "disappear" quite easily and I was wondering if anyone was aware of this problem
(2003)

' Vars are defined when the database opened:

' Public Vars for the Valuations form
Public Task_Subform As Form
Public Task_Subform_Control As Control
Public Val_Form As Form

********************* then..

Public Function RAV_SetVars()
'These Vars are set either at Form_Current if there are
'records in the subform or when the first record is added
' to the subform

' Parent Form
Set Val_Form = Form_Add_Edit_Valuations
' Continous Subform
Set Task_Subform_Control = Val_Form.AllTasks_Subform_SF
Set Task_Subform = Val_Form.AllTasks_Subform_SF.Form

The idea being that I don't have to pass form and subform variables in and out of other functions and can just use the Shortened Names to refer to them in code.

But when I attempt to use these vars in other modules they are set to "nothing"( but not always). For example:
Function Do_Debug (ParentValuation As Form)

'This works fine…
ParentValuation.DebugText = ParentValuation.DebugText & vbNewLine & "Val_Finish_Current_Task"

'This barfs sometimes– error 91 – object variable or with block
' variable not set
Val_Form.DebugText = Val_Form.DebugText & vbNewLine & "Val_Finish_Current_Task"



Also I've noticed that my Debug_On public varaible, which is set in a "main" form that never closes is also being unset.

What's going on?

 
All public variables are unset when you reinitialize the project in debug mode.

Hope This Helps, PH.
FAQ219-2884
FAQ181-2886
 
It may be that you need to fully qualify the paths to the public variables by preceeding them with the form name as outside of the scope of the form they may not be recognised without it.

Also, if you're passing a form to a function, it defeats the object of using the function that way if you don't use the value you passed it (you may as well use a sub without parameters), it also takes away the generic nature of a function. You are already passing the form value By Reference, why do you want to change things to work like this?

HarleyQuinn
---------------------------------
The most overlooked advantage to owning a computer is that if they foul up there's no law against wacking them around a little. - Joe Martin

Get the most out of Tek-Tips, read FAQ222-2244 before posting.

 
also, if any procedure fails and or is 'canceled' all vars are instantly out of scope (" ... object variable not set ... ")




MichaelRed


 
Thanks Guys (or Girls if appropriate), I'm sort of getting the message that I probably just better not use Public Vars. I know at the moment I have been passing the form in by reference in some cases but as the functions and procedures are specific to one form and one subform I figured I could make things a little cleaner and more readable by using Public Vars instead. A few more questions:

"MichaelRed (Programmer) 2 Apr 09 7:33
also, if any procedure fails and or is 'canceled' all vars are instantly out of scope (" ... object variable not set ... ")"

Does this mean when a procedue hits an error and is caught by the on error statement?

and also
PHV (MIS):
"All public variables are unset when you reinitialize the project in debug mode. "

Does that mean when I use breakpoints or watches? what exactly does "reinitialize" mean?

Thanks for your help though - I think I'll just have to rewrite the code and pass the forms and subforms through each function/procedure explicity.

Ciao,
Lea



 
No if you trap the error the variables stay in scope.

But not sure how much cleaner it could be if you are calling this from the on current event. Unless you come up with a one letter name there is nothing much shorter than "Me".
from the Form
code...
to pass the main form
call someFunction(Me)
to pass the subform
call someFunction(Me.Task_Subform_Control.form)
or if calling from the subform and referencing the mainform
call someFunction(Me.parent)

code...

public someFunction(frm as access.form) as someVarType

end function

 
Thanks MajP,

No it's not cleaner without the public vars, I'm re-writing it now. Calling the functions from the forms looks pretty ok but the procedures and functions they call look pretty silly passing in and out the same variables each time. The functions and procedures are in a separate module because the same functionality is called from both the form and the subform.

I've just made the decision that public variables are too dodgy - they work 90% of the time but that's not enough.

Lea

 
so if your function or subroutine is specific to a form and subform, you are correct. There is no need to pass in arguments. But you can shorten your code by doing this inside your function/procedure.

public yourProcedureOrFunction()
dim Val_Form as access.form
dim Task_Subform as access.form

set Val_Form = forms("Form_Add_Edit_Valuations")
set Task_Subform = Val_Form.AllTasks_Subform_SF.Form

Now in the rest of the procedure
Val_Form.property = ...
Task_subform.property = ....

end if
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top