The Following Code Shows the Kind of Wrapper You Need to Place in Your Business Function

The following code shows the kind of wrapper you need to place in your business function to support the calling of external DLLs. This method uses dynamic linking to call a DLL’s functions. Dynamic linking has the following advantages over static linking:

· If a client machine does not have the DLL in question, a static link will cause an access fault. In Dynamic linking, your business function will detect this condition ahead of time and bypass calling a non-existent function.

· With Dynamic linking, you will not require CALLBSFN to be linked with a custom .lib.

That being said, here is the code:

typedef int (*FUNCTION1)(LPARAM); // Function Prototype

int CallFunction1(LPARAM lParam)

{

HINSTANCE InStan; // DLL instance handle

FUNCTION1 lpfnDllFunc; // Function pointer

DWORD errNum; // Error value

UINT retVal; // Return value

InStan = LoadLibrary("CustomDLL"); // Load the custom DLL. DLL must be somewhere in the search path to succeed

if(InStan != NULL) // If DLL was loaded correctly,

{

lpfnDllFunc = (MYPROC) GetProcAddress(InStan,"_Function1@4"); // Get the function address in the DLL

if (!lpfnDllFunc) // If we did not retrieved the function address successfully, then handle error and return

{

// handle the error

errNum = GetLastError();

FreeLibrary(InStan);

//return Some error Code

}

else // Otherwise, we’re good to go. Call the function!

{

// call the function

retVal = (lpfnDllFunc)((LPARAM)lParam);

}

}

}

Some important points:

· In the above example, I set up a call to _Function1@4 in CUSTOM.DLL.

· The “typedef” at the beginning of the code defines the function prototype. E.g. if your DLL exported a function called int GetNextPosition(int CurPos), then the typedef would read: typedef int (*GetNextPosition)(int);

· The “LoadLibrary” will not work if the DLL is not in the search path.

· The GetProcAddress is tricky. To avoid mistakes, run “DUMPBIN /exports CUSTOM.dll > out.lst” to get a listing of all the DLL’s exported functions. Any function that you wish to call must be typed verbatim as it appears in out.lst when you make the GetProcAddress call (including the leading “_” and the @<number> part of the function name.) For your information, the @<number> in the function name represents the number of bytes in the parameter list for the function.

· You may want to centralize the LoadLibrary and GetProcAddress calls so that each call to the custom DLL re-uses this portion of the code.

There you have it. It may take some trials to get the above to work for your custom DLL. Please contact me let me know if this solution will work for you.

Have fun.