public variable

[Chris]

I have defined

Public editconst as Boolean

I set editconst on a command button click, and the immediate window returns
the correct value.

However, when I go to use it on a later form the value gets 'lost'
The immediate window returns
" "
when quizzed about editconst.

Where is the value going?

 

[Nikos Yannacopoulos]

Chris,

Maybe an untrapped error occurred in your code after you set the value,
and before you tried to read the public variable? That's the problem
with public variables, they are reset in this case.
A viable alterbnative is to store the value in a control on a form
instead, which does not suffer from this problem. The control, or even
the form itself, can be hidden, as long as the form stays open. So, if
you have a switchboar or other form that is open at all times, you can
plavce the control there, otherwise you might make a form just for the
purpose, open it at startup and hide it right away.

HTH,
Nikos

 

[Dirk Goldgar]

I have defined

Public editconst as Boolean

I set editconst on a command button click, and the immediate window
returns the correct value.

However, when I go to use it on a later form the value gets 'lost'
The immediate window returns
" "
when quizzed about editconst.

Where is the value going?

In addition to what Nikos has said, make sure that you have defined the
variable in a standard module, not a form module. Public variables
defined in form, report, or other class modules last only as long as the
instance of the object that contains them, and can only be referenced by
way of a reference to the object; e.g.,

Forms!MyForm.editconst

Only public variables defined in standard modules are globally
accessible by name alone.

 

[Chris]

Thankyou both Nikos and Dirk. The big trick with Access is to know the little
tricks!!!!

One thing - Nikos pointed out that an untrapped error might be causing the
problem. How do I find if I have one, and what is the correct procedure/good
programming technique for 'trapping' an error?

I am keen to gain a good knowledge of proper programming methods that ensure
a 'tight' database.

Thanks again
Chris

 

[Dirk Goldgar]

Thankyou both Nikos and Dirk. The big trick with Access is to know
the little tricks!!!!

One thing - Nikos pointed out that an untrapped error might be
causing the problem. How do I find if I have one, and what is the
correct procedure/good programming technique for 'trapping' an error?

I am keen to gain a good knowledge of proper programming methods that
ensure a 'tight' database.

Very good. An untrapped, or unhandled, error is one that is raised by
your application and not handled by error-handling code that you write.
Such errors are then dealt with by Access's default error-handling
routine, which displays the description of the error and, depending on
your option settings, may allow you to debug the code. But it also
tends to rest the VBA project, so that all global variables are returned
to their uninitialized states.

To avoid having this happen, put error-handling code in (at least) all
your top-level VBA procedures. By "top-level" procedures, I mean those
that are not called by other procedures you write, but rather are
triggered by events. You can also write whatever specialized
error-handling you want for lower-level procedures that are called from
the top-level procedures, but if a lower-level procedure doesn't have
its own error-handling code, its errors will be handled by a
higher-level procedure's error-handler, if there is one, so you don't
*necessarily* have to write an error-handler for every procedure.

By error-handling code, I refer to using the On Error statement to
define what will happen and where code execution will continue in the
event of an error being raised by your code. Most often you will want
to use the "On Error GoTo" form of the statement, to transfer control to
an error-handling section in the procedure, from which section,
eventually, the Resume statement is used to continue execution after the
error has been dealt with. An alternative to this is "in-line"
error-handling, which is done by using the "On Error Resume Next"
statement. In that case, your own code checks after executing each
statement, to see if an error has occurred, and deals with errors right
there.

For more information about VBA error-handling, I suggest you start with
the VBA help topic for the On Error statement, and branch out from
there.

 

[Chris]

Once again - thank you.

Very good. An untrapped, or unhandled, error is one that is raised by
your application and not handled by error-handling code that you write.
Such errors are then dealt with by Access's default error-handling
routine, which displays the description of the error and, depending on
your option settings, may allow you to debug the code. But it also
tends to rest the VBA project, so that all global variables are returned
to their uninitialized states.

To avoid having this happen, put error-handling code in (at least) all
your top-level VBA procedures. By "top-level" procedures, I mean those
that are not called by other procedures you write, but rather are
triggered by events. You can also write whatever specialized
error-handling you want for lower-level procedures that are called from
the top-level procedures, but if a lower-level procedure doesn't have
its own error-handling code, its errors will be handled by a
higher-level procedure's error-handler, if there is one, so you don't
*necessarily* have to write an error-handler for every procedure.

By error-handling code, I refer to using the On Error statement to
define what will happen and where code execution will continue in the
event of an error being raised by your code. Most often you will want
to use the "On Error GoTo" form of the statement, to transfer control to
an error-handling section in the procedure, from which section,
eventually, the Resume statement is used to continue execution after the
error has been dealt with. An alternative to this is "in-line"
error-handling, which is done by using the "On Error Resume Next"
statement. In that case, your own code checks after executing each
statement, to see if an error has occurred, and deals with errors right
there.

For more information about VBA error-handling, I suggest you start with
the VBA help topic for the On Error statement, and branch out from
there.

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)