quote:
Originally posted by Heffy
Thanks for the help so far, guys!
However, Cookie, the spam variable is used alot in the project - it's just my temporary variable.
In other words it is
not used thruout the project. A temporary variable shouldn't be made globally like you did. If you need a temporary variable you declare it in the procedure you need it.
Global variables should only be used if you need to variable to retain its value thruout the project.
It is bad practice to simply declare all variables as global (and prone to errors, as you experienced).
quote:
Originally posted by Heffy
Edit: On the undefined variable, iniSettings - that's what I called the ini variable, until I shortened it.
Use 'Option Explicit' in
all modules, forms, classes, whatever, to avoid such mistakes.
quote:
Originally posted by Chestah
Don't forget Cookie 
, Microsoft is advising people not to use ini's and use XML files to store data in. It's alot easier to manipulate XML files and its also alot better for importing settings or importing data into other applications 
.
There is no reason why you should not use INI's, at all. The advise from Microsoft has got nothing to do with security issues, easyness or whatever else. Instead, it has everything to do with the policy that Microsoft takes into trying to push people to use a new way in storing stuff instead of using an old, but very decent and solid way of storing stuff (just as they try to push people from leaving VB and jumping to VB.NET). There is no valid basis why you should not use INI's in any way, especially in projects like this. It is a very wide spread and seriously misconception that using INI's would be bad, less efficient or whatever.
/ 
