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....
<Craig K> wrote in message news:eTcZ%23LmhGHA.4896@TK2MSFTNGP05.phx.gbl...
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.
Thanks!
Craig
"Ben Voigt" <rbv@nospam.nospam> wrote in message
news:%23TVRFulhGHA.4896@TK2MSFTNGP05.phx.gbl...
"Marcus Heege" <NOSPAM@heege.net> wrote in message
news:u0ahHjThGHA.4404@TK2MSFTNGP05.phx.gbl...
Hi Craig,
<Craig K> wrote in message
news:u%23XnZJOhGHA.3956@TK2MSFTNGP02.phx.gbl...
Marcus,
I tried that and unfortunately it did not help.
Thanks.
Craig
"Marcus Heege" <NOSPAM@heege.net> wrote in message
news:%23LWdt7NhGHA.3916@TK2MSFTNGP04.phx.gbl...
Hi Craig,
<Craig K> wrote in message
news:%23bBnNtNhGHA.4044@TK2MSFTNGP03.phx.gbl...
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
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