GetMessage Function MFC Mixed mode dll link problems...

G

Guest

All,

I have a MFC Mixed mode dll which is working well. I am now tring to use a
regular C++ class from another DLL which has a method called GetMessage.
When I link I get 2 error messages:


MyClass.obj : error LNK2028: unresolved token (0A00074C) "public: class
CMessage * __thiscall CTransmitMessage::GetMessage(int)"
(?GetMessage@CTransmitMessage@DSS@@$$FQAEPAVCMessage@2@H@Z) referenced in
function "private: void __thiscall CMyClass::processStateResponse(class
CStateResponse const &)"
(?ProcessStateResponse@CMyClass@DSS@@$$FAAEXABVCStateResponse@2@@Z)
MyClass.obj : error LNK2019: unresolved external symbol "public: class
CMessage * __thiscall CTransmitMessage::GetMessage(int)"
(?GetMessage@CTransmitMessage@DSS@@$$FQAEPAVCMessage@2@H@Z) referenced in
function "private: void __thiscall CMyClass::processStateResponse(class
CSaveStateResponse const &)"
(?ProcessStateResponse@CMyClass@DSS@@$$FAAEXABVCStateResponse@2@@Z)

CMyClass::processResponse( stateMsg )

....

CMessage* pMessage = stateMsg.GetMessage( i );

....

This class and function have been used for years, but I get this specicific
link error when I use it from any MFC Mixed mode dll. If I rename the
function something other than GetMessage, I do not get the linking errors.
This leads me to think there is some conflict on the GetMessage name with
the .Net Framework but I do not know how to resolve this. Any ideas?

Thanks!

Craig Klementowski
 
M

Marcus Heege

Hi Craig,

All,

I have a MFC Mixed mode dll which is working well. I am now tring to use a
regular C++ class from another DLL which has a method called GetMessage.
When I link I get 2 error messages:


MyClass.obj : error LNK2028: unresolved token (0A00074C) "public: class
CMessage * __thiscall CTransmitMessage::GetMessage(int)"
(?GetMessage@CTransmitMessage@DSS@@$$FQAEPAVCMessage@2@H@Z) referenced in
function "private: void __thiscall CMyClass::processStateResponse(class
CStateResponse const &)"
(?ProcessStateResponse@CMyClass@DSS@@$$FAAEXABVCStateResponse@2@@Z)
MyClass.obj : error LNK2019: unresolved external symbol "public: class
CMessage * __thiscall CTransmitMessage::GetMessage(int)"
(?GetMessage@CTransmitMessage@DSS@@$$FQAEPAVCMessage@2@H@Z) referenced in
function "private: void __thiscall CMyClass::processStateResponse(class
CSaveStateResponse const &)"
(?ProcessStateResponse@CMyClass@DSS@@$$FAAEXABVCStateResponse@2@@Z)

CMyClass::processResponse( stateMsg )

...

CMessage* pMessage = stateMsg.GetMessage( i );

...

This class and function have been used for years, but I get this
specicific link error when I use it from any MFC Mixed mode dll. If I
rename the function something other than GetMessage, I do not get the
linking errors. This leads me to think there is some conflict on the
GetMessage name with the .Net Framework but I do not know how to resolve
this. Any ideas?

Thanks!

Craig Klementowski

what happens if you
#undef GetMessage
in the file that causes the errors?

Marcus
 
M

Marcus Heege

Hi Craig,

Marcus,

I tried that and unfortunately it did not help.

Thanks.

Craig

Is it possible to repoduce the poblem in a small VS solution, so that I can
do further reseach?
 
B

Ben Voigt

Marcus Heege said:
Hi Craig,



Is it possible to repoduce the poblem in a small VS solution, so that I
can do further reseach?

Please view the DLL containing CTransmitMessage with DependencyWalker. Most
likely while the DLL was built, it renamed the function to GetMessageA.

www.dependencywalker.com
 
G

Guest

Ben,

It does seem to do that. How I do get it to not do that? Why does it work
from all other non mixed mode dll's?

Thanks!

Craig
 
B

Ben Voigt

Ben,

It does seem to do that. How I do get it to not do that? Why does it work
from all other non mixed mode dll's?

Marcus has it right, the windows.h header file (or one of the hundreds of
files it #includes) defines GetMessage to GetMessageA or GetMessageW to
choose either the Unicode or ANSI version of the builtin (user.dll)
GetMessage API. Your managed program probably doesn't #include <windows.h>,
so you're not getting the same replacement.

You can:
(1) #include <windows.h> in your caller
or
(2) #undef GetMessage in the exporting dll
or
(3) in your header file for the class, above the class definition, use a
static inline function instead of a macro for the GetMessage thing as
follows:

#undef GetMessage
static inline BOOL GetMessage(
LPMSG lpMsg,
HWND hWnd,
UINT wMsgFilterMin,
UINT wMsgFilterMax
) {
#if UNICODE
return ::GetMessageW(lpMsg, hWnd, wMsgFilterMin, wMsgFilterMax);
#else
return ::GetMessageA(lpMsg, hWnd, wMsgFilterMin, wMsgFilterMax);
#endif
}

This will shim only the Windows API GetMessage and not all other occurances
of the identifier. (inline functions are resolved based on scope while
macros hit everything). Since it is inline, there will be no extra function
call overhead -- it is just as efficient as a macro.
 
G

Guest

Ben,

Great #3 works for me. I think I may prefer to rename the function in the
long run though. Never did like #defines that much....

Thanks Guys!

Craig
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top