You can determine whether the class is operating as part of an executable or a DLL by making use of parameters provided by the Application object provided by Visual Basic. I set a variable called IAmADll via the following statement.

I perform this statement in the Class_Initialize subroutine and then use it wherever necessary to control the use of code that is specific to either the DLL or EXE situation.

You can put your INI file almost anywhere you like. Back in the days of Windows 3.x these files often were placed in the Windows directory but there is a better place. That place is the directory of the executable that uses it. Why? To keep all parts of a program together. This facilitates archival/backup operations as well as putting the INI file where a user most likely would look for it. The Application object parameters will tell you where the program resides via the following statements.

Now you know where the program is located and you have a nice default name for the INI file. If the class is only being operated by itself as a DLL, the name is good enough. If, however, it is a part of a larger DLL or an EXE, such a fixed name might be a little restrictive. To handle this situation, I include a public SetupINI subroutine that allows the user of the class to set the path and INI name to something more appropriate. If you use this alternate name source, you must also defer any initializations that depend on it until the user of the class actually requests some kind of action. I take care of this by establishing an INIRead flag that starts out FALSE and putting all initialization code into a single subroutine (GetProfile) that is called at the beginning of any user accessible function. GetProfile checks the INIRead flag to determine if initialization is required and sets the flag to TRUE after performing the initialization.

The moveable INI file

Defining the INI file name as including the path where it resides insures that all accesses to it go to the same place; you wouldn't want it to go roaming about. I always use fully qualified path names for all files; particularly those identified in the INI file. But sometimes you need to move an application from where you developed it or maybe you get to install it on someone else's machine. For such a case, you want to be able to merely copy your INI file to its new location and expect it to work for any file that is collocated with the application. To do this I include the AddPath function to all initializations of file names obtained from the INI file and the RemoveMyPath function for copying file names to the INI file. AddPath adds MyPath to the file name if the name is not already fully qualified. RemoveMyPath removes MyPath from a file name if it finds it.

Consistently formatted error messages are a must whether working with classes or just modules. I always include the following subroutine in every code file so that I can be sure that any reported error contains as much information as possible.

I also include a public Error property so that the using code can retrieve the error information.

I've included a sample class template that includes everything described above so that you can use it, where appropriate, in your development efforts. To download the template, just click here.

© 2000, Verified Software Products Company