Passing global/public variable between forms (1 Viewer)

[Galaxiom]

use tempvars as suggested in #3.
unlike global variable, tempvars tend to persist even
when you encounter runtime error.
while global vars are destroyed when error occurs on your code.

Sigh. Myths persist. Call it semantics if you like but errors do not clear VBA variables. It is the choice to reset that does it.

It is very easy to avoid the reset.

 

[Galaxiom]

Procedures are like a building. Work to be done should be delivered and results returned through the front door. Global variables are the equivalent of doing business through a window with an itinerant passerby. It is a disaster waiting to happen.

 

[arnelgp]

Sigh. Myths persist. Call it semantics if you like but errors do not clear VBA variables. It is the choice to reset that does it.

before you examine my example, there are already threads (outside this forum), experiencing variables being reset when runtime errors occurs.
google them.

and here is the example.
when divide by zero occurs, select End (button) on the error message.
now on Immediate window type:

?g_variable
?tempvars!tvariable

which one is destroyed and which one is preserved?
if the db is .accde/accdr there is no choice (but the End button on the error message).

this is also true on Global ribbon instance (custom ribbon).

 

[sonic8]

when divide by zero occurs, select End (button) on the error message.

The End statement as well as the End button in the error message box both terminate the (VBA) application. In the runtime environment this actually ends the application while in "normal" Access the Access application stays active but is reset.

The question is: Is it generally better that TempVars keep their value? Definitely no!
It depends on the variable and the situation. If the error happened while the code was supposed to set the variable to a new value, it is equally bad if a (normal) variable is reset or if a temp var keeps the old value that should have been updated.
After an unhandled runtime error occurred, the state of the application cannot be trusted anymore.
The caveat must be: "Handle possible errors!", not "Use tempvars so that your application may (or may not) be able to continue executing in an undefined state after an unhandled error occurred."

 

[sonic8]

Global variables are the equivalent of doing business through a window with an itinerant passerby. It is a disaster waiting to happen.

I would rephrase that to: "... the equivalent of doing business through all of the buildings windows to any number of passersby at the same time."

 

[arnelgp]

both terminate the (VBA) application

it terminate the VBA not the application.

 

[The_Doc_Man]

After an unhandled runtime error occurred, the state of the application cannot be trusted anymore.

Absolutely, categorically, positively true.

Here we have no argument.