By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,633 Members | 1,053 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,633 IT Pros & Developers. It's quick & easy.

CALLBACK problem

P: n/a
I have written a Regular DLL with many Export Functions and one CALLBACK fun
ction .
The callback function declared in the .cpp file of the Regular DLL is as fol
lows:

typedef BOOL (CALLBACK* ExProcessMessage)(UINT msg, LPVOID lpParam);
//
ExProcessMessage MyProcMsg;

----------------------------------------------------------------------------
--------------------

I have written an MFC Application which is dynamically linked to this Regula
r DLL.

In the MFC Application (SDI Application with DOC/VIEW support) , I also use
threading functionalities.

In the MFC Application I have declared a global function as a CALLBACK funct
ion as follows:
BOOL CALLBACK OnCMFMessage(UINT msg, LPVOID lpParam1);

I initilaise the address of this function to the pointer varaible declared i
n DLL (MyProcMsg) as follows in my MFC App code:
InitializeCB((long)&OnCMFMessage); -- (whereas the InitializeCB is a export
function in DLL to initialise the callback function pointer)

----------------------------

Now the problem is , when I call the CALLBACK function (OnCMFMessage) from m
y DLL by using the function pointer , the callbcak function is not at all ca
lled. What could be the reason?????

But when I use the as said above with a Win32 application, it worked fine. M
y callbcak is called. And I got the desired result.
The problem was only with the MFC App which I said above.
Jul 23 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
Mohamed Fysal wrote:
I have written a Regular DLL with many Export Functions and one CALLBACK fun
ction .
DLLs are off-topic here. Just so you know...
The callback function declared in the .cpp file of the Regular DLL is as fol
lows:

typedef BOOL (CALLBACK* ExProcessMessage)(UINT msg, LPVOID lpParam);
//
ExProcessMessage MyProcMsg;
That's not a function. That's a pointer to a function. It is left
uninitialised.
----------------------------------------------------------------------------
--------------------

I have written an MFC Application which is dynamically linked to this Regula
r DLL.
MFC is off-topic here.
In the MFC Application (SDI Application with DOC/VIEW support) , I also use
threading functionalities.
Threading is off-topic here.
In the MFC Application I have declared a global function as a CALLBACK funct
ion as follows:
BOOL CALLBACK OnCMFMessage(UINT msg, LPVOID lpParam1);
OK.
I initilaise the address of this function to the pointer varaible declared i
n DLL (MyProcMsg) as follows in my MFC App code:
InitializeCB((long)&OnCMFMessage); -- (whereas the InitializeCB is a export
function in DLL to initialise the callback function pointer)
Whatever. Since you don't provide the contents of 'InitializeCB', you
could simply not mention it. There is no proof here that initialisation
of your "address of this function" actually works. Or that it doesn't.
----------------------------

Now the problem is , when I call the CALLBACK function (OnCMFMessage) from m
y DLL by using the function pointer , the callbcak function is not at all ca
lled. What could be the reason?????
The reason could be that your 'InitializeCB' doesn't work very well.
The reason could be that your function is never defined. Or there can
be a whole host of other reasons. Since you provided no substantial
amount of code to illustrate your problem, nothing can be said or done.
But when I use the as said above with a Win32 application, it worked fine. M
y callbcak is called. And I got the desired result.
The problem was only with the MFC App which I said above.


If you think that MFC is the root of the problem (at least you make it
sound that it might be), try an MFC newsgroup, one of (or all):

comp.os.ms-windows.programmer.tools.mfc
microsoft.public.vc.mfc

If you think that your function's place in a DLL is a problem (which it
might be as well), try the newsgroup for your os programming:

comp.os.ms-windows.programmer.win32

V
Jul 23 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.