IsKindOf question

Started by
6 comments, last by Zeke 22 years, 3 months ago
Is there any issues related to CObject::IsKindOf() to do with multithread programming. Im calling it from a worker thread and its not returning what I expect it to return. I get a HWND use CWnd::FromHandle to get a CWnd and then do IsKindOf(RUNTIME(Class)) and it returns true. I then pass that same HWND into the worker thread AfxBeginThread(Func,Hwnd) do EXACTLY the same thing to the hwnd as i just did seconds before (but in the worker thread) but this time the IsKindOf function returns false. Has anyone got any ideas? because it seems as though I am doing exactly what microsoft tell me i should do (in passing HWND rather than objects to the worker thread) yet it just isnt working. Ive been searching through the msdn and any website I can find but it seems as though im doing it the correct way so im a bit lost. Thanks for any help
Just my thoughts take them as you will. "People spend too much time thinking about the past, whatever else it is, its gone"-Mel Gibson, Man Without A Face
Advertisement
IsKindOf just looks up through lists of inheritence strings which should be static and constant, so it doesn't need to be synchronized.

Rather, your problem is in FromHandle. FromHandle looks up in MFC's internal map of HWND->CWnd* to find your pointer. However, this map is in thread-local storage. This is one of the many functions in MFC you should only call from the thread that creates the window. If you call FromHandle in the original thread that "owns" the window, you will get your original CWnd-derived pointer back. If you call it from a worker thread, you should get a temporary CWnd.

Edited by - Stoffel on January 8, 2002 4:29:57 PM
Thanks for the reply.

So if I cant use FromHandle in the worker thread how can I get the valid CWnd?

Ive been told that what Im trying to do just isnt possible and I need to use PostMessage() from the worker thread to post messages to the main thread to take care of anything to do with the window. I havent tried that yet (im about to now) but surely there is a better way of doing it, because now I need to do things totally different depending on what thread im in and of course Im going to need to know what thread I am in because as far as I know there is no way for me to find that out when I need to.Its going to look pretty messy.

Thanks again for the reply
Just my thoughts take them as you will. "People spend too much time thinking about the past, whatever else it is, its gone"-Mel Gibson, Man Without A Face
OK an update to my situation and a different but related problem has arose. Im trying to use the PostMessage() idea. Ive set up the user messages and the handlers for this in my CMainFrame class. I start the thread and in the controlling function I call PostMessage. Because my controling function is not a CWnd member function I need to use the :ostMessage() rather than CWnd:ostMessage. This means I need the HWND of the main app however as I cannot reliably (or at all) use the HWND how can I call :ostMessage passing in the real HWND?

AfxBeginThread(ControlFunc,AppHwnd);

UINT ControlFunc(pParam)
{
PostMessage((HWND)pParam,msg,param,param);
//fails i assume due to the fact pParam is no longer valid
//in this thread
}

I cant make the controlling function a method of one of my views (i.e. UINT CListViewDerivedClass::ControlFunc(LPVOID pParam)) because it has to be static and then can only call static member functions, so it cannot call CWnd:ostMessage().

So can anyone tell me how to PostMessage from a worker thread or give me any other ideas?

Thanks for any help you can offer

Just my thoughts take them as you will. "People spend too much time thinking about the past, whatever else it is, its gone"-Mel Gibson, Man Without A Face
Stop sticking your smiley tongue out at me!! =) j/k

What you have should work, and it's what we do with our multi-threaded apps. You sure your message isn't getting there? Make sure your message is some offset from WM_USER if you're sending a custom message.

edit: elaborating a bit:
The reason you shouldn't call a lot of the functions in MFC from another thread is because most of the function calls are actually wrapped SendMessages, and you can't (shouldn't? not sure the real reason) use SendMessage from a different thread. However, PostMessage is always safe from another thread, and even from other applications I believe.

Edited by - Stoffel on January 9, 2002 12:45:19 PM
Oops heh heh i didnt realise : and p creates a smiley lol.

Anywho you were right about the fact i was doing it the correct way. I found the problem late yesterday and it was in my message handler functions. I wasnt using afx_msg before the return typ in the functions. As soon as I added that it started working.

Thanks very much

p.s. throughout this multithreading prob ive been reading up a lot about multithreaded mfc apps and I have read that the reason you shouldnt sendmessage() across threads is because there is a good chance of locking one of the threads causing the other to lock (deadlock i think its called??) due to the fact that the one thread has to wait for the other thread to process the message and return (cant remember the actual reason- something like the one thread has to wait for the other thread which is locked due to the first thread or something)
Just my thoughts take them as you will. "People spend too much time thinking about the past, whatever else it is, its gone"-Mel Gibson, Man Without A Face
SendMessage has a race-condition? otherwise I can''t see how two threads could dead-lock by calling it... also, I was under the impression that your WndProc need to be reentrant because SendMessage happens asyncronsouly from the message pump...
- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara
Look at this article, specifically the sections about message routing and avoiding message deadlocking:

http://msdn.microsoft.com/library/en-us/dndllpro/html/msdn_winthr.asp

This topic is closed to new replies.

Advertisement