Set string later use as filter

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have some code that I run to update my tables, and it also creates a filter
statement as a string that I would like to use later for the form (not
directly after I've run the code, so I can't just use the 'where' condition
in the 'open form' method). How would I go about storing/accessing this
string for later use when I open the form?
 
Use a global variable as in

Global [variableName] as String

I always use 'glb_' as a prefix to my globals to indicate that the
variable is a global and I stick them all in a free standing module
named Global Variables just to have them all handy.
 
Hi,
you can for example store this filter in public variable, or you can use a
local table to save filter there, and then retrieve when necessary
 
My aversion to global variables is exceeded only by my aversion to the GoTo.
Here is a function that replaces the need (there really is never a need) for
global variables.

Function MyPubVar(Optional varPubVal As Variant) As Variant
'Returns current value if no parameter passed
'Stores value passed
'Establishes a default value for first call

Static varSaveVal As Variant

If IsMissing(varPubVal) Then
If IsEmpty(varSaveVal) Then
varSaveVal = "GotIt!" 'The initial value goes here
End If
Else
varSaveVal = varPubVal
End If
MyPubVar = varSaveVal
End Function
 
Could you elaborate as to the differences between the two and your
aversion to globals?
 
The wider the scope of a variable, the more apt the value of the varialbe is
to be suspect. If you are the only developer in an application, then it
doesn't matter as much.
In reality, there is not that much difference between the two. I quess I
picked up the preference in other languages where globals are a little harder
to manage. It is mostly style, as in avoiding the GoTo.
Global variables can be over used, in other words, used when they are not
necessary. So, if you put a taboo on them, you may not eliminate them, but
hopefully make people think before using them.
In this particular case, we don't really know where his code exists. Could
it be in the same module that he does the updates that he calls the OpenForm?
If so, a module level variable would be more appropriate.
 
Murp said:
I have some code that I run to update my tables, and it also creates a filter
statement as a string that I would like to use later for the form (not
directly after I've run the code, so I can't just use the 'where' condition
in the 'open form' method). How would I go about storing/accessing this
string for later use when I open the form?
Click to expand...


Another place you can save a value is in a text box on an
always open form, such as your startup form.

This is a safer place than a Public variable in a standard
module(reset on any unhandled error), but will not survive
closing the database as putting it in a table will.
 
So then I wasn't wacked out in using Global's to replace multiple
DLookup's of the same information across multiple SUBs? In my DB, the
table tblTransports is more or less the core of the database. As such, I
had multiple SUBs (createOutlookAppointment, createLedgerEntry,
updateLedgerEntry, etc.) that used DLookups to grab the relevant
information from the table - date, time, origination, destination, etc,
etc. To streamline things, I created a SUB - loadTransport() that takes
the record ID of the transport and sets related global variables for use
in the various SUBS. The globals are set by using DAO to grab the
record. The thinking is that it would be easier to use Globals as
opposed to 10+ DLookups on the same table.

David H
The wider the scope of a variable, the more apt the value of the varialbe is
to be suspect. If you are the only developer in an application, then it
doesn't matter as much.
In reality, there is not that much difference between the two. I quess I
picked up the preference in other languages where globals are a little harder
to manage. It is mostly style, as in avoiding the GoTo.
Global variables can be over used, in other words, used when they are not
necessary. So, if you put a taboo on them, you may not eliminate them, but
hopefully make people think before using them.
In this particular case, we don't really know where his code exists. Could
it be in the same module that he does the updates that he calls the OpenForm?
If so, a module level variable would be more appropriate.

:
Click to expand...
 
Nor will it survive if the FORM is closed.

Marshall said:
Another place you can save a value is in a text box on an
always open form, such as your startup form.

This is a safer place than a Public variable in a standard
module(reset on any unhandled error), but will not survive
closing the database as putting it in a table will.
Click to expand...
 
I don't think that is wacked out at all. There is valid justification for
breaking almost any rule if the alternative makes sense by improving
efficiency.
 
Back
Top