Use an instance of a class across events?

[Jesper F]

I have a drag-n-drop rutine with code running in the MouseDown, MouseUp,
MoveMove and other events.
Variables are created and used in one event and used in the next.
Could I use class programming in this situation? Is it possible to
instantiate class in on event and keep working with it in another? It limits
the use of the class that everything has to initiate, run and terminate in
each event.
Any input is appreciated, thanks

/ Jesper

 

[Klatuu]

If you need variables to be available in multiple procedures in your form
module, dim them at the module level, right after the Declarations and before
any code.

In this case, the above technique might be more efficient that using a class
module. The class module adhears to the same scope rules as varialbes.

 

[George Nicholson]

It limits the use of the class that everything has to initiate, run and

terminate in each event.

You might want to review the concept of variable scope.

A class would pretty much follow the same scope as any other object
variable, or variable of any datatype for that matter.

For instance, you could declare a recordset variable at the top of a form
module, instantiate it during form_open and the object would be available to
all events of the form.

Same thing for any custom class, or any other variable type.

Variables of any type could also be declared at the top of a General code
module (i.e., not Form, Report or other class-related module) and used
throughout the application.

 

[Klatuu]

Good Info, George. I agree with one exception-Global varialbles. You are
techincally correct; however, Global variables are not to be trusted. For
example, if any unhandled error occurs, they loose their value. Unless you
use Hungarian or a similar naming convention, you could accidently create a
local variable with the same name and confuse Access, your app, and yourself.
Also you have to be very careful where you use them so another procedure in
your code doesn't put in an unexpected value.

IHMO, If you think you need to use a global variable, you really need to
rethink your design. In eight years of coding in Access, I have never used a
global variable.

 

[George Nicholson]

I use them all the time, but they are rarely called directly, they are
called by Get/Set functions that will derive a value (by either prompting
the user or fetching the value last used by the current user) if they are
'empty'. So they become sort of defacto application properties... Simple
personal preference, but I prefer using GetSomeID() functions in queries and
code than relying on endless Form!Control references to get a value when I'm
not actually on the Form in question. Just seems to make things more robust
and portable.

But, your point is well taken regarding being prepared for the loss-of-value
continguency (which I would think applies to Form/Report level variables as
well). The option of chosing a Global/Application variable scope is
nevertheless available for use, with caution.

And we can always simply prohibit our apps from having unhandled errors

 

[Klatuu]

Module level varialbes( form, report, standard) do not loose value on errors,
only those defined as Global. Don't ask, I don't know

They are unlike an application property in that they are not presistent.
Once set, an application property will retain its value until changed even
when you close and reopen the application.

If you are using set and get functions, here is an idea that will interest
you that is not subject the the error problems of global variables (I have
used this technique). Use a function with a Static variable. In the example
below, the function will always return the current value of the static
variable. To change the value, you pass it a value. If it receives no
value, the static variable remains

Public Function FoobahNumber(Optional varNewVal As Variant) As Long
Static lngOldVal As Long

If Not(IsMissing(varNewVal) Then
lngOldVal = varNewVal
End If
FoobahNumber = lngOldVal

End Sub

 

[Jesper F]

For instance, you could declare a recordset variable at the top of a form

module, instantiate it during form_open and the object would be available
to all events of the form.

Does this have a memorydisadvantage? Could I loose say the recordset if I'm
no longer in the event that created it?

 

[Klatuu]

If you dim your recordset at the top of the module after the declarations but
before any code, it will be visible to all code in the module, whether it is
an event procedure or a user defined function or sub. If you call code from
outside the module, the external module will not see it.

There is no difference that I know of in memory useage and you will not
loose visibility by chaning events.

 

[Jesper F]

There is no difference that I know of in memory useage and you will not

loose visibility by chaning events.

If I - say Dim a recordset at the top of a forms module.
And the Set the recordset in the forms Open-event, then the recordset is
available as long as the form is open.

What if the table is updated in the meantine by another user?


/ Jesper

 

[Klatuu]

If the recordset varialbe is dimmed at the top of the module, it doesn't
matter where you open the recordset. How you define the recordset determines
what happens if other users add records. It you don't want to see changes,
set the recordset to read only
Set rst = CurrentDb.OpenRecordset("SomeTableOrQuery"dbReadOnly")