initializing global variables when they are defined?

[Guest]

Is there some way to initialize fixed global variables when they are defined?
For example, if I want the variable MyName to always be John can I do
something like:

Public MyName as string = "John"

 

[Guest]

Try this

Public Const MyName As String = "John"

 

[Guest]

Thanks twice, I appreciate your answering both my questions.

 

[Guest]

I get the same error, mybe there is a better solution, but you can create the
global variable
global CarRet As String

Assign the chr to this variable, using the load event of the first form that
pop up when the application runs

CarRet = Chr(10) & Chr(13)
===============================
Or the Autoexec, what ever you are using.
===============================
Another option will be, to start a new post asking that question, mybe there
is a way to assign a chr to a constant

 

[Albert D.Kallal]

Do be aware that there is a good number of built in constants you can use


Happens to be one I use a lot.....

vbCrLf Chr(13) + Chr(10) Carriage return-linefeed
combination
vbCr Chr(13) Carriage return character
vbLf Chr(10)

Look up constants in the help.....

 

[Guest]

How nice; just what I need. Thanks.

 

[David C. Holley]

Its my understanding that once the declaration is made that that's it.
If a piece of code breaks, its just a matter of fixing that problem,
recompiling to clean up the problem and keep going. There's no starting
over neccessary.

 

[Guest]

Its my understanding that once the declaration is made that that's it.
If a piece of code breaks, its just a matter of fixing that problem,
recompiling to clean up the problem and keep going. There's no starting
over neccessary.

I think maybe Wayne was referring to how Access drops the heap when
execution is stopped.
For example, I store a user ID in a global variable, but it gets wiped if a
bug occurs that forces a user to stop execution. Of course, that's one more
incentive for me to make sure that every possible exception is handled
gracefully in code!

 

[David C. Holley]

Or to present your users with the Blue Screen of Death. (or maybe just
have some very robust error handling)

David H

 

[Dirk Goldgar]

I think maybe Wayne was referring to how Access drops the heap when
execution is stopped.
For example, I store a user ID in a global variable, but it gets
wiped if a bug occurs that forces a user to stop execution. Of
course, that's one more incentive for me to make sure that every
possible exception is handled gracefully in code!

One way to deal with this is to define it as a public property, by
creating a Property Get statement in a standard module, and having the
procedure return the literal value.

 

[Guest]

One way to deal with this is to define it as a public property, by
creating a Property Get statement in a standard module, and having the
procedure return the literal value.

Interesting. I haven't used property procedures; what are they good for?
I image the values set would be database-specific. This would work just
fine for my purposes, as each user has their own copy of the FE.
Thank you!

 

[Dirk Goldgar]

Interesting. I haven't used property procedures; what are they good
for? I image the values set would be database-specific. This would
work just fine for my purposes, as each user has their own copy of
the FE.
Thank you!

By creating a Property Get/Let/Set procedures in standard modules in
your database, you effectively create user-defined properties for your
database's VB project. And because they are public procedures, you can
refer to these properties via function expressions in controlsources if
you want. You can also use Property procedures to cope neatly with the
problem of global variables losing their values when the VB project is
reset (as, for example, due to an unhandled error).

Here's a simple example of what I was talking about. Consider waynemb's
desire to have a global variable that returns the CR/LF combination.
Yes, I know there's already a defined VB constant for that -- two, in
fact -- but suppose there weren't? He could do as Ofer suggested and
define a global variable, then use some event to set its value:

' In a standard module's Declarations section:
Public CarRet As String

' In some event:
CarRet = Chr(13) & Chr(10)

But (a) you have to rely on that event to run, and (b) there's the risk
of an unhandled error causing the VB project to be reset and the
assigned value to be lost.

Instead, you could define a public Property Get procedure in a standard
module:

Public Property Get CarRet() As String

CarRet = Chr(13) & Chr(10)

End Property

Then anywhere you want to use a carriage return/line feed combination,
you can use this property; e.g.,

strFullAddress = _
strAddr1 & CarRet & strAddr2 & CarRet & strCityStateZip

Here's a more complex example. Suppose you have a configuration
value -- say, LicenseeName -- that is frequently referred to in your
app. You want to store this value in a table, but you don't want the
cost of doing a DLookup every time you need it. You could write a pair
of Property Get and Let procedures for this value:

'----- start of module code -----
Dim mvarLicenseeName As Variant ' private, defined at module level

Property Let LicenseeName(pstrNewValue As String)

If Len(pstrNewValue) = 0 Then
Err.Raise 380 ' Invalid property value
Else

mvarLicenseeName = pstrNewValue

CurrentDb.Execute _
"Update tblConfiguration Set LicenseeName = " & _
Chr(34) & mvarLicenseeName & Chr(34),
dbFailOnError

End If

End Property

Property Get LicenseeName() As String

' Lookup the value if it isn't in memory.
If IsEmpty(mvarLicenseeName) Then
mvarLicenseeName = DLookup("LicenseeName", "tblConfiguration")
End If

LicenseeName = mvarLicenseeName

End Property
'----- end of module code -----

Now you can have code in various places like this:

Me!lblLicenseeName.Caption = LicenseeName

and

LicenseeName = Me!txtEnterNewLicenseeName

and a controlsource for a text box like this:

=LicenseeName()

 

[David C. Holley]

So then if I have a table for default values such as
tblDefaultValue
txtDefaultValueName
txtDefaultValue
txtDefaultValueType

I could use LET/GET to set the default value ONCE and forgo doing
multiple DLookups() each time I used the default value. Then if I update
a value I would simply do what? call the LET function to change the
value in memory?

David H

 

[Dirk Goldgar]

So then if I have a table for default values such as
tblDefaultValue
txtDefaultValueName
txtDefaultValue
txtDefaultValueType

I could use LET/GET to set the default value ONCE and forgo doing
multiple DLookups() each time I used the default value.
Right.

Then if I
update a value I would simply do what? call the LET function to
change the value in memory?

You wouldn't have to explicitly call the Let function; just assigning
to the property would do that. Then, in your Property Let procedure, it
would be up to you and your code whether you just wanted to change the
in-memory value, or whether you wanted to change the in-memory value
*and* update the corresponding value in tblDefaultValue.