scheng
asked on
CreateWindow and multiple threads
Hello,
I am writing an application with an edit control in it. It seems that the normal way to do this (not using MFC but using the plain C-style SDK) is to create a main window and in the WndProc callback of the main window in the WM_CREATE event, create the edit control there. If I do that, everything works just fine. Now supposed I want to do something totally weird. That is, when the WM_CREATE event is reached, istead of calling CreateWindow to create the edit control there, I signal another thread to do the CreateWindow (passing it the appropriate information to do the create), and sleep() until the other thread respoonds that it is done, and then return from the WM_CREATE event. For some reason this does not work for me. The other thread always hangs (or in some infinite loop) in CreateWindow (inside USER32!), and I have no idea why.
Is there something fundamental that I am missing ? For instance, win32 API forbids one to create child windows in a thread different than the parent window ?
--sheila
I am writing an application with an edit control in it. It seems that the normal way to do this (not using MFC but using the plain C-style SDK) is to create a main window and in the WndProc callback of the main window in the WM_CREATE event, create the edit control there. If I do that, everything works just fine. Now supposed I want to do something totally weird. That is, when the WM_CREATE event is reached, istead of calling CreateWindow to create the edit control there, I signal another thread to do the CreateWindow (passing it the appropriate information to do the create), and sleep() until the other thread respoonds that it is done, and then return from the WM_CREATE event. For some reason this does not work for me. The other thread always hangs (or in some infinite loop) in CreateWindow (inside USER32!), and I have no idea why.
Is there something fundamental that I am missing ? For instance, win32 API forbids one to create child windows in a thread different than the parent window ?
--sheila
In most Win32 programs, the main thread is designated to work with UI elements. It has all the code that deals with creating and deleting windows. If a thread needs to have access to a particular window, then you can pass the window handle to the thread for it to use.
I suspect that it is because your new thread does not have a message loop.
ASKER
I don't have a basic problem like not having the window handle. I have actually figured out my problem although the answer is, I can't do what I want to do. The "problem" is, while in WndProc, it will not process another message until either WndProc returns or WndProc calls another windows graphics function (ie. CreateWindow) that directly results in another message. I am in the latter case but since I moved the CreateWindow of the edit control into another thread with the original WndProc waiting (sleeping), it will not be preempted to process any messages that is a result of the CreateWindow from another thread.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
That's a good answer. :) Can you answer this question. I'm pretty much playing with an edit control to write an editor that can edit unicode (wide character) text files that is better than Notepad. The edit control, I think, has a maxinum number of editable characters that you can put on it. I briefly saw something called a rich edit control that is supposed to be better. The question is, which is the best predefined text widget (control or window) to use for a general purpose editor that can handle an unlimited lines of text ?
There is no problem creating controls in a different thread.
ASKER
I know that there isn't a problem per se with creating a control in a different thread. But the way I was creating it would not work (according to Charles Petzold's Programming Windows 95). I was suspending the parent window's WndProc thread inside WndProc while trying to create a child control in another thread. When a child control is being created in another thread, the parent window's WndProc will get a message and it must be processed before the child control can be created (ie. before the create call returns). But since I have the parent's thread suspended, it isn't going to be able to process the message and hence I have my deadlock.
I believe that that is the difficulty with my original scheme of doing things. Please tell me if I'm wrong and why.
I believe that that is the difficulty with my original scheme of doing things. Please tell me if I'm wrong and why.
exactly