How can I get "CONSTANT" behavior from a variable (Constant magic)?

  • Thread starter Thread starter bobg.hahc
  • Start date Start date
B

bobg.hahc

running access 2k;
And before anything else is said - "Yes, Virginia, I know you can NOT
use a variable to set a constant (that's why it's constant)".

BUT - my problem is - I want a constant, that I can set from a
variable (one time)!!!

When my application starts, the user is prompted to make a selection
from a list.
I want that selection to go into a global variable, and NEVER CHANGE
while the application is running. This means that if the application
encounters an unexpected error - this value is NOT lost.

If the user wants to change this value, they should have to close the
application and restart.

This is the BEHAVIOR I'm looking for.....

Is this behavior possible, and if so, how?

BTW -
I should mention, that I successfully accomplished this by actually
programatically inserting a global constant statement into a "globals
module" ! (the insertion statement, of course used a variable to
define the statement). Problem is, (no surprise), this can NOT be done
in a run-time application.... ;o)

thoughts or discussion?

TIA!!
Bob
 
Perhaps if you explain a bit more about this value, how it is created and
how it is going to be used, someone might be able to help.

Jeanette Cunningham
 
The only thing that comes to mind would be to have a utility table that you
write this value to when your app opens, then either refer to it directly
each time you need it, or, if you are a good do-bee and have error handling
routines on all procedures, re-assign it to a global variable if an error is
encountered.

I use such a table for holding things like company addresses, phones numbers,
fax numbers, etc, that are used in printouts. That way, if any of these
things change, the end user can change the information, which wouldn't be
possible if it
were hardwired. You can also use it to store information about the last
record that was worked on, so that the user can pick up where they left off.
 
running access 2k;
And before anything else is said - "Yes, Virginia, I know you can NOT
use a variable to set a constant (that's why it's constant)".

BUT - my problem is - I want a constant, that I can set from a
variable (one time)!!!

When my application starts, the user is prompted to make a selection
from a list.
I want that selection to go into a global variable, and NEVER CHANGE
while the application is running. This means that if the application
encounters an unexpected error - this value is NOT lost.

If the user wants to change this value, they should have to close the
application and restart.

This is the BEHAVIOR I'm looking for.....

Is this behavior possible, and if so, how?

BTW -
I should mention, that I successfully accomplished this by actually
programatically inserting a global constant statement into a "globals
module" ! (the insertion statement, of course used a variable to
define the statement). Problem is, (no surprise), this can NOT be done
in a run-time application.... ;o)
Click to expand...


Putting the value in a text box on an always open, hidden
form is much safer then a global variable.

A one row (one field?) table is the natural choice in a
database system.
 
hi Jeanette;
TX for your reply...

Basically, I have 2 separate [to the user] applications. Each uses the
same tables, and nearly the same forms / user interface.

I don't want the user confused about which application he/she's in, so
I want them to choose 1, and live with it as long as it's open. So I
have an autoexec that asks which app they want, and I would like that
answer to be my "application constant"...

Marshall's solution sounds like a good one, but I was curious if you
had another....

TX...
Bob
 
hi Marshall;

TX, this sounds like a very workable solution, and I definitely like
it better than a global variable... I'll give it a try...

TX
Bob
 
Linq:

I appreciate your reply...

I should have mentioned that I did think of storing it in a table...
I just shy away from doing this, because of performance... there's
dlookup; which is Really bad (performance-wise).
I could always do a sql call, but prefer to just grab it out of memory
if at all possible....

Of course, this would have been a fall-back position, saving any other
ideas....

TX again!
Bob
 
or a dozen lines in a Class module...
Click to expand...

Hmm....
Mike - interesting idea; although, admittedly, I haven't done much
with classes...
You don't have to spell out every letter, but could you give me an
idea of how this would work?

TX IA!
Bob
 
Marsh's solution is easy to implement. You can do a similar thing with
creating a settings table in the front end to store the value and do a
DLookup each time you want to retrieve the value. There is a third way of
using Properties - but it is more advanced stuff to wrap your head around.

Jeanette Cunningham

hi Jeanette;
TX for your reply...

Basically, I have 2 separate [to the user] applications. Each uses the
same tables, and nearly the same forms / user interface.

I don't want the user confused about which application he/she's in, so
I want them to choose 1, and live with it as long as it's open. So I
have an autoexec that asks which app they want, and I would like that
answer to be my "application constant"...

Marshall's solution sounds like a good one, but I was curious if you
had another....

TX...
Bob


Perhaps if you explain a bit more about this value, how it is created and
how it is going to be used, someone might be able to help.

Jeanette Cunningham
Click to expand...
Click to expand...
 
If the table is in the front end, the performance issue is a non-issue, the
user is only fetching the data from a table stored on their own desktop -
nothing needs to be fetched from linked tables across the network.

Jeanette Cunningham
 
AHH....
a lookup table in the front-end.... yea, performance should be much
less an issue with that, but I still think dlookup is costly....

But; I'll keep that in mind; in situations that may be the best
solution....

And, actually, I hadn't thought to use properties... I already use
them for app version reporting, and such...
Not hard to use at all.... and probably "cheaper" than a dlookup even
to a local table.....


TX!
 
Here is a more detailed link:

http://support.microsoft.com/kb/209968

Here is a simple example:

Add a Class Module to your project called clsMyProp


Add the following Code to the module:
+++++++++++++++++++++++++++++++
Option Compare Database
Option Explicit

Private mvMyClassVar As String

Private Sub Class_Initialize()
'if you wanted a Default Startup Value
'You would set it here:
'mvMyClassVar = "Initialized"
End Sub

Public Property Let MyClassValueToStore(s As String)
mvMyClassVar = s
End Property

Public Property Get MyClassValueToStore() As String
MyClassValueToStore = mvMyClassVar
End Property

Private Sub Class_Terminate()
'Any Cleanup Code for the Class you Would do Here
'MsgBox "Class Terminated", vbInformation, "Class Example"
End Sub

+++++++++++++++++++++++++++++++

Add the following Code to a Form module or a Bas Module
Notes: In whatever module you add this code,
(recommend using subMain in a standard module as your startup)
the declaration of Public will
make your class visible throughout your project. You have to set
a reference
to the variable "clsMyClass" ONCE to instantiate the Class Object,
thereafter you set a value to it and the class private variable
" mvMyClassVar" will hold the value for reference whenever you
request it as
in the example sub "RetrieveTheValue"

+++++++++++++++++++++++++++++++
Option Compare Database
Public clsMyClass As clsMyProp

Private Sub ClassMyProp()
Set clsMyClass = New clsMyProp
clsMyClass.MyClassValueToStore = "TheOneShotValue"
RetrieveTheValue
End Sub
Private Sub RetrieveTheValue()
MsgBox clsMyClass.MyClassValueToStore
End Sub
+++++++++++++++++++++++++++++++++++++++++
 
A class may be more "elegant" in a computer science sort of
way and it's worth considering if you have a lot of things
to keep track of.

A custom property is also valid.

Both of those require some code to create, but IMO, their
limited scope is the deciding factor. A trivial public
function that retrieves a variable's value and an always
open form's controls both have a scope that extends to
control expressions, queries as well as VBA procedures.
 
FWIW, i use >private< global variables, with matching Get/Set routines.
Set: assign value to the global variable AND store it in a local table,
"tblUserSetting"
Get: returns the value of the global variable. If that value (0 or "")
indicates its been reset, retrieve it from tblUserSetting (or prompt user).

On Startup, you can also grab the value from tblUserSetting to "preselect" a
value for the user to chose from.
 
Mike;

terrific information!
microsoft does have some good info - IF you can find it :) that link
was VERY helpful, but your example was much better at illustrating the
concept...

appreciate it... TX;

I think I will try to use this to manage my application setting...
just seems "cleaner" :-)
Bob
 
I think what I like about the class solution is this - and it is a
guess on my part:
it seems to me that the class solution would utilize less system
resources than having a form & control open & hidden all the time.

granted, the resources in question are no doubt trivial, so maybe it
is more an intellectual comfort of know that I saved 5 bytes of
memory... ;-)

Bob

A class may be more "elegant" in a computer science sort of
way and it's worth considering if you have a lot of things
to keep track of.

A custom property is also valid.

Both of those require some code to create, but IMO, their
limited scope is the deciding factor. A trivial public
function that retrieves a variable's value and an always
open form's controls both have a scope that extends to
control expressions, queries as well as VBA procedures.
--
Marsh
MVP [MS Access]

[email protected] said:
TX, this sounds like a very workable solution, and I definitely like
it better than a global variable... I'll give it a try...
Click to expand...
Click to expand...
 
George,
TX much for your input.

I actually also use the technique for other "user", or "system" type
settings. It just seemed a little "un-permanent" for what I wanted to
do here.

although, your comment leaves me with another idea of using this
technique with classes... again not for this specific situation, but
for many others...

good tip... TX
 
Hey Mike-

I have to say using classes, I was able to create a very elegant
solution that does ALMOST exactly what I want!

I created a property, that basically check's to see if the property is
already null. if it is null, it set's it; if not, it raises an error
"one-time write property".

VERY nice; except that an un-handled error still clears the class
variable....

any way around this that you know of.... (again the "real" desire is
to do this without the use of tables as an intermediate storage - I
can do this if I used a "session stamped record" in a table).

TX again!
Bob
 
Marshall Barton said:
A class may be more "elegant" in a computer science sort of
way and it's worth considering if you have a lot of things
to keep track of.

A custom property is also valid.

Both of those require some code to create, but IMO, their
limited scope is the deciding factor. A trivial public
function that retrieves a variable's value and an always
open form's controls both have a scope that extends to
control expressions, queries as well as VBA procedures.
Click to expand...

All solutions have their time and purpose.
Classes, though slightly more comples than a public variable go the additional
step of providing information hiding.
The liklihood of tromping on a public variable is measurably greater than the
inadvertant access and disturbance of a property in a class.
You choose the solution that fits the circumstances.
Marsh
MVP [MS Access]


TX, this sounds like a very workable solution, and I definitely like
it better than a global variable... I'll give it a try...
Click to expand...
Click to expand...
 
Back
Top