Global variable resets to zero ??? (2 Viewers)

Partly for this reason I have wrapper functions for tempvars.

Option Compare Database
Option Explicit

Public Function TempVarsBoolean(ByRef VarName As String) As Boolean
TempVarsBoolean = Nz(TempVars(VarName), False)
End Function

Public Function TempVarsDouble(ByRef VarName As String) As Double
TempVarsDouble = Nz(TempVars(VarName), 0)
End Function

Public Function TempVarsDate(ByVal VarName As String) As Date
If IsDate(TempVars(VarName)) Then
TempVarsDate = DateValue(Nz(TempVars(VarName), #1/1/2099#))
Else
TempVarsDate = #1/1/2099#
End If
End Function

Public Function TempVarsLong(ByVal VarName As String) As Long
TempVarsLong = CLng(Nz(TempVars(VarName), 0))
End Function

Public Function TempVarsString(ByVal VarName As String) As String
TempVarsString = CStr(Nz(TempVars(VarName), "*"))
End Function
Very interesting! I'm trying to fully digest the meaning of this now.
 
Are you sure? Or did I miss something?

In a standard module:

Code:
Option Compare Database
Option Explicit

Public Sub Foo()
    Static myStaticVariable As Long
End Sub
                  
Public Sub Bar()
    Debug.Print myStaticVariable ' <-- Compiler raises 'Variable not defined' here
End Sub

From previously referenced VBA Language Reference, section 5.3.1.2, Static Procedures, Runtime Semantics:

All variables declared within the <procedure-body> of a static procedure have module extent.
All variables declared within the <procedure-body> of a non-static procedure have procedure extent.

I hope that clarifies what I said. But the two "All variables..." quotes are cut/paste from the .PDF file in question.
 
Ok, I can follow and agree that.
But before you wrote it would have module scope. ;)
HOWEVER: A variable declared STATIC, even if in the private variable area of a sub or function, has "module" scope.
 
Decades ago I was in the habit of prepending "G" to global variables and "L" to local variables. Some times your naming conventions will prevent many headaches!
 
Partly for this reason I have wrapper functions for tempvars.

Option Compare Database
Option Explicit

Public Function TempVarsBoolean(ByRef VarName As String) As Boolean
TempVarsBoolean = Nz(TempVars(VarName), False)
End Function

Public Function TempVarsDouble(ByRef VarName As String) As Double
TempVarsDouble = Nz(TempVars(VarName), 0)
End Function

Public Function TempVarsDate(ByVal VarName As String) As Date
If IsDate(TempVars(VarName)) Then
TempVarsDate = DateValue(Nz(TempVars(VarName), #1/1/2099#))
Else
TempVarsDate = #1/1/2099#
End If
End Function

Public Function TempVarsLong(ByVal VarName As String) As Long
TempVarsLong = CLng(Nz(TempVars(VarName), 0))
End Function

Public Function TempVarsString(ByVal VarName As String) As String
TempVarsString = CStr(Nz(TempVars(VarName), "*"))
End Function
George, do you have the same for setting them?
 
I am not, as many are, totally opposed to Globals. But with the advent of TempVars, tempvars do seem like a better option.
However, I like the explicit typing of globals, and people play awfully fast and loose with temp vars, which I don't like.
Six to one...

Through my work on generalization of code, I started to admire the Globals.
On this moment I use Globals to describe the Control, the Control-description, and the Form on which the Control is placed.
The Control-description describes how the Control - for the user - should behave. Of course, I also use other globals to steer the underlying generalized processes.
Basically, with this construct, I can automate almost complete applications, just by defining their different Control-descriptions, and by defining where the controls are placed on the form.

When a control on a form is entered, it becomes "bound" to the corresponding Control-description. So no Classes are needed to distinguish between different controls. Even, I don't need different control types!

It makes no difference what kind of application it is, they all use the same library database, housing the generalized code, and only two dynamical forms for all display purposes.
 
While I agree that globals are very good language elements, and I have used them a lot, they suffer from one major drawback. If your error handling is not tight, you sometimes reach what is loosely referred to as the Last Chance error handler, the one that offers you the option to DEBUG (i.e. drop you into debug mode at the line creating the error), RESET (reset application memory), and - VERY RARELY - you might get the option to CONTINUE. But usually not.

When that happens, the next thing that is going to happen - when you finally take the RESET option - is that all modules, both class and general, get unloaded. The side effect of that action happens because all Public variables are in the declaration areas of their respective modules. Unloading the modules unloads the variables (dissolves them). I.e. RESET resets memory wholesale. If you then enter debug mode and try to examine something in a module, in essence you re-instantiated the module... by re-loading it. The previous values are no longer there. Re-instantiation of the containing module usually makes the variables be 0, "", null, nothing, empty, etc.

TempVars, some created objects, and Dictionaries persist across this RESET action. "Ordinary" variables - even Static ones - do not.
 
George, do you have the same for setting them?
No, because that does not seem useful to me since the resulting tempvar would still be a untyped. I'm willing to be corrected, though, if I'm wrong.
 

Users who are viewing this thread

  • Back
    Top Bottom