Global variables - again - sorry
in [Forms]
|
From: Dennis on 21 Feb 2010 23:31 Jeanette, Thanks for the information. I have a little bit of reading, some testing, and a lot of head scratching. Thanks, Dennis
From: Paul Shapiro on 22 Feb 2010 08:27
You can get the db directory with CurrentDB.Name, which returns the complete path and file name. That would eliminate one of the global variables. "Rod Plastow" <RodPlastow(a)discussions.microsoft.com> wrote in message news:B6FB1B77-CB60-48CC-87EF-096CEBC82B1B(a)microsoft.com... > 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. |