Bad DLL calling convention when accessing my dll from VB
I'm pretty new to C++, but know a little VB6 and some more C#.
I have inherited a dll which uses MFC and exposes 3 functions. I can access and pass values between the dll and an AutoIt3 script, no problems there. The problem arises when I try to access the dll from VB6 I keep getting "Bad DLL calling convention" whenever I try to pass a parameter to any of the functions.
Because I know little of C++ I have created a few test applications using VS.NET 2005 MFC DLL Wizard using "MFC in a shared DLL" with a .def file that defines some test functions. All my test applications work from VB6 I can pass values in and get values back, that's one of the reasons I have posted this in the C++ forum rather than VB6.
As soon as I #include <afxwin.h> (or anything else afx'y) and pass in a value I get "Bad DLL calling..." it's driving me nuts!
Unfortunately I can't use the .def file approach with the dll code as it uses a different way of declaring the exported functions
#define My_API __declspec(dllexport)
My_API int Funct(bool value1);
My_API int Funct1(char* value1);
My_API int Funct2(HWND hwnd,char* value1, char* & value2, int value3);
My_API void Funct3(char* value1, int& value2, int& value3, int& value4, int& value5);
} (I know I said 3 functions, but Funct is one I added for testing)
Then all functions are prefixed
My_API int Funct1(bool value1)
I suppose my question is why, when using the __declspec(dllexport) approach does passing a boolean parameter cause the "Bad DLL calling..." error?
If there aren't any parameters on a function I get the returned value no problems in VB6.
Hope that all makes sense and I hope the mods understand I think this is the correct forum for my post.
Re: Bad DLL calling convention when accessing my dll from VB
Read up on __stdcall and __cdecl. That is the probable reason for your error. One function is using a calling convention to load the parameters and the called functions is using the other calling convention -- outcome -- disaster.
You must make sure that both caller and called use the same calling convention.
Last edited by Paul McKenzie; October 15th, 2010 at 12:08 PM.