Changes to Header Files in DLLs

Compiler Directives Needed

Once you have tested your class, it is time to build the dll. To allow your classes to be seen outside of the current project they have to be declared as _export. At the same time in order to compile your cpp file inside the dll, the classes must be declared as _import. The following is from the Borland Object Windows Programmers Guide.2

Define shared classes by:

• Conditionally declare your class as either _export or _import
• Pass a TModule* parameter to the window constructors (in some situations).

Note: If you declare a shared class in an include file that is included by both the DLL and an application using the DLL, the class must be declared _export when compiling the DLL and _import when compiling the application. You can do this by defining a group of macros, one of which is conditionally set to _export when building the DLL and to _import when using the DLL. For example,

#if defined(BUILDEXAMPLEDLL) 
#define _EXAMPLECLASS __export 
#elif defined (USEEXAMPLEDLL)
#define _EXAMPLECLASS __import 
#else 
#define _EXAMPLECLASS 
#endif 
class _EXAMPLECLASS TColorControl : public TControl {
public:
.
.
.
}; 

By defining BUILDEXAMPLEDLL (on the command line, for example) when you are building the DLL, you cause _EXAMPLECLASS to expand to _export. This causes the class to be exported and shared by applications using the DLL.

By defining USEEXAMPLEDLL when you're building the application that will use the DLL, you cause _EXAMPLECLASS to expand to _import. The application will know what type of object it will import.

Namespace Considerations

One problem with this definition is that every program that uses this dll must know about the identifier USEEXAMPLEDLL. This leads to extensive namespace problems. In addition there is no need to just add the words _export and _import, you can entirely redefine class. Each dll must have a unique name that it uses to replace class. This name is only used a few times, so it can be very long (and descriptive). I generally want to use class when testing, so I have an identifier ClassNameTESTDLL, and I use _import when building the dll, so I have an idenifier ClassNameBUILDDLL. My identifiers in this case are RIGHT_BUTTON_LISTBOX_TESTDLL and RIGHT_BUTTON_LISTBOX_BUILDDLL. My compiler directives for this class are

#if defined(RIGHT_BUTTON_LISTBOX_TESTDLL)
#define RIGHT_BUTTON_LISTBOX_CLASS class
#elif defined (RIGHT_BUTTON_LISTBOX_BUILDDLL)
#define RIGHT_BUTTON_LISTBOX_CLASS class _export
#else 
#define RIGHT_BUTTON_LISTBOX_CLASS class _import
#endif
RIGHT_BUTTON_LISTBOX_CLASS RightButtonListBox : public TListBox {
public:
.
.
.
};

Test Your New Headers

Once you have adjusted your header, make sure that every file that imports this header in your test program has the line

#define RIGHT_BUTTON_LISTBOX_TESTDLL

before the header is included. Now you should be able to run your test program again. When we convert this program to a DLL, we will replace all of the compiler directives that define RIGHT_BUTTON_LISTBOX_TESTDLL with directives that define RIGHT_BUTTON_LISTBOX_BUILDDLL.