My Assistant
Site Message
(Message will auto close in 2 seconds)
  |
 Public Variables
|
|
 Nov 26 2007, 01:15 AM
Post
#1
|
|
|
UtterAccess Addict Posts: 203  |
Quick question. If I put the following into a module:
Public lngMyEmpID As Long does that mean that the variable IngMyEmpID is available for any form and will remain unchanged unless it is written over by another function? For example, if the variable is assigned the value "2" by a function, will that value stay there after the form has been closed, and can that value be used by another function on a totally different form? Thanks, hope I was clear. Not really sure how to express what I'm trying to say. |
 |
 
|
|
Nov 26 2007, 01:20 AM
Post
#2
|
|
|
UtterAccess VIP Posts: 4,622 From: North Carolina, USA |
The quick answer -- Yes, you are correct.
Here is a detailed explanation: Visual Basic Sample Program: Public vs. Private Variables |
|
|
|
|
Nov 26 2007, 03:07 AM
Post
#3
|
|
|
UtterAccess Addict Posts: 203 |
Great, thanks for that. My next question....why do I need to define this variable in a module? Is it possible to define it in a form as public? Will the result be the same thing?
|
|
|
|
|
Nov 26 2007, 03:18 AM
Post
#4
|
|
|
UtterAccess VIP Posts: 20,187 From: Colorado |
Using public variables is not a good idea -- their values are lost as soon as you break your code. Instead, you can use database properties
CODE 'Set and Delete Database Properties
'~~~~~~~~~~~~~~~~~~~~~ RunSetDatabaseProperty Sub RunSetDatabaseProperty() Dim mPropName As String _ , mPropType As Long _ , mValue mPropName = "DefaultUserID" mPropType = dbLong mValue = 27 SetDatabaseProperty mPropName, mPropType, mValue MsgBox mPropName & " is " _ & CurrentDb.Properties(mPropName) _ & " for this database", , "Done" End Sub '~~~~~~~~~~~~~~~~~~~~~ SetDatabaseProperty Function SetDatabaseProperty( _ pPropName As String _ , pPropType As Long _ , pValue) As Byte 'written by Crystal 'set up Error Handler On Error GoTo Proc_Err CurrentDb.Properties.Append CurrentDb.CreateProperty( _ pPropName, pPropType, pValue, False) Proc_Exit: Exit Function Proc_Err: If Err.Number = 3367 Then CurrentDb.Properties(pPropName) = pValue Resume Proc_Exit End If MsgBox Err.Description, , _ "ERROR " & Err.Number _ & " SetDatabaseProperty" 'press F8 to step through code and debug 'remove next line after debugged Stop: Resume Resume Proc_Exit End Function '~~~~~~~~~~~~~~~~~~~~~ RunDeleteDatabaseProperty Sub RunDeleteDatabaseProperty() Dim mPropName As String mPropName = "DefaultUserID" DeleteDatabaseProperty mPropName MsgBox mPropName & " has been deleted", , "Done" End Sub '~~~~~~~~~~~~~~~~~~~~~ DeleteDatabaseProperty Function DeleteDatabaseProperty( _ pPropName As String _ ) As Byte 'written by Crystal 'set up Error Handler On Error GoTo Proc_Err CurrentDb.Properties.Delete pPropName Proc_Exit: Exit Function Proc_Err: MsgBox Err.Description, , _ "ERROR " & Err.Number _ & " DeleteDatabaseProperty" 'press F8 to step through code and debug 'remove next line after debugged Stop: Resume Resume Proc_Exit End Function |
|
|
|
|
Nov 26 2007, 03:26 AM
Post
#5
|
|
|
UtterAccess Addict Posts: 203 |
Ok, now I'm sufficiently confused. What I will do is implement the user login form set out on:
http://www.databasedev.co.uk/login.html There is a section of the code which seems to allocate a public variable a value, and then closes the original logon screen. What I want to know, is will that public variable (defined in a module) stay there for the duration of time the user is using access? Thanks in advance. |
|
|
|
|
Nov 26 2007, 03:38 AM
Post
#6
|
|
|
UA Editor + Utterly Certified Posts: 22,722 From: Melton Mowbray,Leicestershire (U.K) |
Hi
One of the easiest options I found when I needed to store/hide my variables specially the global ones that get canceled out if the application falls over and needs to recover itself is to have a "hidden" application parameter form sitting in the background. In some cases this form is based on a table of parameters that the application will use directly from startup and as you move through the application and find you need to hold some variable value I populate a control in the form. Remember this form is hidden and and all that is required when using these parameters is a simple reference call... (just an option..) |
|
|
|
|
Nov 26 2007, 03:44 AM
Post
#7
|
|
|
UtterAccess VIP Posts: 20,187 From: Colorado |
Hi djcox100 (what is your name)
unless you intend to leave the form open in its hidden state -- and it does not sound like you are going to do that, it sounds like you intend to "store" the values in memory with global variables. If you do that, your data is susceptable to getting lost. Although lots of people use them, global variables are not a good idea to use for more than a temporary period of time because their values can be lost. Global values are not written anywhere, they exist only in memory. Database properties, on the other hand, ARE written, so they can be set and retrieved with greater success. The code I gave you basically has 2 procedures, one to set a database property (you make up a name and, if it does not exist, the procedure will create it) and one to delete a database property. The "Run" procedures are examples of how to use the other 2 procedures. The link you posted uses a public variable to store the information, which is not a good idea. You can still pattern after the example but, instead of storing the information in a public variable, write it to a database property. |
|
|
|
|
Nov 26 2007, 03:45 AM
Post
#8
|
|
|
UtterAccess VIP Posts: 20,187 From: Colorado |
I see Larry (Hi Larry!) gets around the problem of lost global variables with a hidden form -- and that is another option.
|
|
|
|
|
Nov 26 2007, 08:14 AM
Post
#9
|
|
|
UtterAccess Addict Posts: 203 |
Sorry for being recalcitrant with this, however, how can the data be lost? Is it when the application crashes? Or just mysteriously disappears. Sorry once again.
|
|
|
|
|
Nov 26 2007, 08:17 AM
Post
#10
|
|
|
UtterAccess VIP Posts: 20,187 From: Colorado |
public variables are lost if you stop your code or, of course, if the application crashes. When you are testing your application, it is convenient to step through code -- but if you do that, the values in your public variables disappear. I simply don't trust them.
|
|
|
|
|
Nov 26 2007, 08:19 AM
Post
#11
|
|
|
UtterAccess Addict Posts: 203 |
Oh, and my name is Darrin.
|
|
|
|
|
Nov 26 2007, 08:25 AM
Post
#12
|
|
|
UtterAccess Addict Posts: 203 |
Ok, got it. Thanks for your help. Do you have an example of a user login where it holds the user information in a hidden form? Thanks once again.
|
|
|
|
|
Nov 26 2007, 08:44 AM
Post
#13
|
|
|
Utter A-fishin'-ado Posts: 17,723 From: Cincinnati, Ohio, USA . . . ><((((°> |
>>it is convenient to step through code -- but if you do that, the values in your public variables disappear.<<
Crystal, Not to disagree this early in the morning, (I've only had a half a cup of java (IMG:http://www.utteraccess.com/forum/style_emoticons/default/wink.gif) ), but simply stepping through code will not destroy public variables. It is only when errors occur in code and the code stops running that variables are lost. You can even have an error occur (while debugging), choose Debug, fix the code, and continue on without losing the values in your variables. Granted it is still considered poor programming technique (there are usually better ways to track variables), but I still use them as a last resort and have never had any issue with them being unexpectedly lost. |
|
|
|
|
Nov 26 2007, 09:37 AM
Post
#14
|
|
|
UtterAccess Addict Posts: 203 |
So is there any way to use a login form to capture a users ID and keep that value, without using public variables and hidden forms?
|
|
|
|
|
Nov 26 2007, 09:46 AM
Post
#15
|
|
|
Utter A-fishin'-ado Posts: 17,723 From: Cincinnati, Ohio, USA . . . ><((((°> |
You have basically about 4 ways ...
Public variables Keep a form open and store values on it Database properties (as Crystal described) Write the values into records in a table Each has their own pros/cons. Some can keep their values even if the DB is exited, some can be accessed from other apps, some are easier to check visually, some are accessed faster than others, etc.. |
|
|
|
|
Nov 26 2007, 09:59 AM
Post
#16
|
|
|
UtterAccess Addict Posts: 203 |
Hmmm....I don't really understand the Database Properties method, and don't understand how that would work to store a users id when they first stat the application. I might go with the safe way and just hide the login form. Thanks everyone for your help.
|
|
|
|
|
Nov 26 2007, 10:01 AM
Post
#17
|
|
|
Utter A-fishin'-ado Posts: 17,723 From: Cincinnati, Ohio, USA . . . ><((((°> |
NP. We're glad to help.
|
|
|
|
|
Nov 26 2007, 10:30 AM
Post
#18
|
|
|
UtterAccess Ruler Posts: 1,150 From: Elizabethtown, KY |
Walter and Crystal,
Just piggybacking on the question. I'm almost done creating a generic login utility. Right now the user has two options to keep user login information alive, which can be set using a property of the login class. 1) Global variable and 2) Class properties (keep login form open and hidden). Would you suggest implementing one of the other two ways you described? Also, which would you recommend, based on your experience, as the most reliable way to keep user information alive during their login and which has the quickest access, all assuming a detailed (global) error handler is employed. |
|
|
|
|
Nov 26 2007, 10:47 AM
Post
#19
|
|
|
Utter A-fishin'-ado Posts: 17,723 From: Cincinnati, Ohio, USA . . . ><((((°> |
TinyGiant,
Let me try to detail each method's strengths/weaknesses and then you can decide... 1. Public variables. Memory resident, so accessing them is fast. Will lose their value if DB is closed or an unhandled error occurs and code stops. Requires little programming. 2. Keep a form open and store values on it. Fast, but keeping the form open consumes memory. OK if your system has a bunch to spare. Will lose their value if DB is closed. Require no programming. 3. Database properties. Fast. Will keep their value if the DB is closed or errors occur. Requires higher level programming. 4. Write the values into records in a table. Slower access. Will keep their value if the DB is closed or errors occur. Easy to access from other programs. Requires moderate programming. Depending on if you want to store who logged in the last time or not (and pre-fill the username when the DB opens) will determine to some extent which methods you will use. Personally I don't mind if the variables are destoyed if an error occurs. If that happens, there's probably a larger issue that I need to handle and the program terminates anyway. |
|
|
|
|
Nov 26 2007, 11:08 AM
Post
#20
|
|
|
UtterAccess Addict Posts: 203 |
For me, a user login would only need to hold the information for the duration that the user is using the application. For my application, the user setting at the beginning will inform what the user can and can't do, so recording it in a temp table doesn't seem to fit my application.
From a performance point of view, what you describe sounds like global variables are better. What do u mean if the cde stops? The code on the initial form, or if any form's code stops, will cause the loss of the variable? |
|
|
|
 |
|
Jump To Forum:
|
Go to Top · Lo-Fi Version | Time is now: 18th May 2013 - 11:29 AM |