Global variables - again - sorry
in [Forms]
|
From: Dennis on 21 Feb 2010 15:55 Hi, When I load my first form in the system, it reads in the following parameters from my INI file. User Name the DOS Path to the Data I store these two value in a global variable and only reference them from that point on. I use the user name to read in a row from the tblUserParm table that has all of the settings for that user. I use the DOS data path to get to different sub-directories under my Access db directory. I will also use it to make automatically re-do my links, but I am not at that point yet. Is this an appropriate use of global variables? Is there any other appropriate use of global variables? Thanks, Dennis
From: Jeanette Cunningham on 21 Feb 2010 17:49 If you are distributing this db as an .mde or .accde, then it is probably OK to use global variables, as I believe that global variables will not be reset when the code is running in an .mde or .accde (from a posting by Albert Kallal explaining this). I prefer to use Property Let and Property Get procedures to store these type of settings. Jeanette Cunningham MS Access MVP -- Melbourne Victoria Australia "Dennis" <Dennis(a)discussions.microsoft.com> wrote in message news:A9862B5F-AF67-48A5-AF49-53E41991D1EC(a)microsoft.com... > Hi, > > When I load my first form in the system, it reads in the following > parameters from my INI file. > > User Name > the DOS Path to the Data > > I store these two value in a global variable and only reference them from > that point on. > > I use the user name to read in a row from the tblUserParm table that has > all > of the settings for that user. > > I use the DOS data path to get to different sub-directories under my > Access > db directory. I will also use it to make automatically re-do my links, > but I > am not at that point yet. > > Is this an appropriate use of global variables? > > Is there any other appropriate use of global variables? > > Thanks, > > > Dennis > > >
From: Dennis on 21 Feb 2010 21:13 Jeanette I will eventually be distributing this db an mde. I do not know about Property Let and Property Get procedures. Any good place to read up on them or will I find them in the different Access books? Thanks, Dennis
From: Jeanette Cunningham on 21 Feb 2010 21:24 Here is the info I have on the topic compliments of mvp Dirk Goldgar. 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. 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 wayne'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 someone esle 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() 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? Right. 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. Dirk Goldgar, MS Access MVP Jeanette Cunningham MS Access MVP -- Melbourne Victoria Australis "Dennis" <Dennis(a)discussions.microsoft.com> wrote in message news:D3E91D14-ADCC-4D29-8281-62B9E052481A(a)microsoft.com... > Jeanette > > I will eventually be distributing this db an mde. > > I do not know about Property Let and Property Get procedures. Any good > place to read up on them or will I find them in the different Access > books? > > Thanks, > > Dennis >
From: Rod Plastow on 21 Feb 2010 21:37
Dennis, To extend Jeanette's reply [Jeanette: I apologise for butting in] - a couple of features you might like to consider and that may eliminate the need for an INI file are: 1. Storing data in the CurrentProject.Properties collection. These values will apply globally to your application irrespective of user. The useful things is the data is persistent between sessions. 2. Storing data in the registry. If you don't know them, look up the SaveSetting, GetSetting, etc. statements. Here VBA stores the data in the HKEY_CURRENT_USER hive so the data can be different for each user. Again the data is persistent between sessions. #2 of course falls down if you move the applcation to another machine - but then so does an INI file solution. There are also some useful built in VBA functions that return the current user, whether the application was started by that user or Automation, etc. Have fun! Rod PS You ask whether there are other uses for global variables. The trite answer is use a global variable for any data that applies to the application as a whole; your use of user-specific data is a good example. However like Jeanette I prefer to keep global variables per se to a minimum. When necessary I place all such variables together with enums, etc. in a clearly named module, a module that contains nothing else but these 'definitions.' They are then easy to find and review. |