views:

459

answers:

5

I'm working on a portability layer for OpenGL (abstracts the glX and wgl stuff for Linux and Windows)... Anyhow, it has a method for creating a Window... If you don't pass in a parent, you get a real window with a frame... If you pass in a parent, you get a borderless, frameless window...

This works fine, as long as I do it all on 1 thread... As soon as another thread tries to create a child window, the app deadlocks in the win32 call "CreateWindow()". Any ideas?

A: 

A window is tied to the thread that creates it (more specifically, to that thread's message queue). A parent window cannot reside in a different thread than its child windows.

Remy Lebeau - TeamB
This is not what I'm trying to do. I want each thread to take care of ONLY the windows that it creates... I just need to create a window with a parent created by another thread...
dicroce
That WILL NOT work. You CANNOT create a parent window in one thread and then create a child window in another thread. They MUST be in the same thread.
Remy Lebeau - TeamB
Hmm... Well, I actually did get it to work... Basically, I just needed to get the parents message pump pumping... then it all started working... But you're comments worry me... How sure are you of this being a bad thing?
dicroce
This is not true. It is possible to create a child on a parent belonging to a different **process**, not to mention different thread.
atzz
A: 

When a child window is created, it can interact with the parent window via SendMessage. But, note that SendMessage across thread boundary blocks threads unlike PostMessage. If the parent window's thread is waiting for the child thread, and the child thread is trying to create a window whose parent is in that thread, then it's a deadlock.

In general, I don't think it's a good idea to make child-parent relationship across the threads. It can very easily make deadlock.

minjang
There is no interaction between parent and child... So I don't know what the SendMessage and PostMessage stuff is for... How sure are you of your second paragraph? Is this a general limitation of Win32?
dicroce
Yes, it is a Win32 limitation. Parent-child window relationships should never cross thread boundaries. Another symptom that is a result of that is DestroyWindow() will not work correct if destroying a parent window whose child windows were created in other threads.
Remy Lebeau - TeamB
Dicroce, there is an implicit SendMessage call between parent and child. So, you'd better to avoid it.
minjang
In my case, the parent will not be destroyed until after ALL of its children have been...
dicroce
A: 

This is an interesting question: A lot of old school win32 guys have told me you CANNOT do this. In researching this, I found this forum: SendMessage(). My current theory is that CreateWindowEx() must send a message (via SendMessage(), so it blocks) to the parent window to ask for permission to exist (or at least to notify of its existence)... Anyhow, as long as that parent thread is free to process these messages, it all works...

dicroce
+1  A: 

There are a lot of replies here saying that you MUST NOT attempt to have child and parent windows on different threads, and rather emphatically stating that it will not work.

If that was so, Windows would put some safeguards in and simply fail out when you attempted to call CreateWindow. Now, there definitely are thread coupling issues that can cause major issues, but, that said with those constraints, this is a supported scenario.

Chris Becke
+3  A: 

This is not a real answer, but since so many people seem to believe that Win32 forbids creating children in other threads than the parent, I feel obliged to post a demonstration to the contrary.

The code below demonstrates creation of a child window on a parent belonging to a different process. It accepts a window handle value as a command-line parameter and creates a child window on that parent.

// t.cpp

#include <windows.h>
#include <stdio.h>

#define CLASS_NAME L"fykshfksdafhafgsakr452"


static LRESULT CALLBACK WindowProc( HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam )
{
    switch ( msg )
    {
        case WM_DESTROY:
            PostQuitMessage(0);
            break;

        case WM_PAINT:
        {
            PAINTSTRUCT ps;
            BeginPaint(hwnd, &ps);
            EndPaint(hwnd, &ps);
            break;
        }
    }
    return DefWindowProc(hwnd, msg, wParam, lParam);
}



int main( int argc, char* argv[] )
{
    HWND parent = (argc >= 2) ? (HWND)strtoul(argv[1], 0, 0) : (HWND)0;
    printf("parent: 0x%x\n", parent);

    WNDCLASS wc = {};
    wc.lpfnWndProc = WindowProc;
    wc.hInstance = (HINSTANCE)GetModuleHandle(NULL);
    wc.lpszClassName = CLASS_NAME;
    wc.hbrBackground = (HBRUSH)(COLOR_ACTIVECAPTION + 1);
    if ( !RegisterClass(&wc) )
    {
        printf("%d: error %d\n", __LINE__, GetLastError());
        return 0;
    }

    const DWORD style = WS_CHILD | WS_VISIBLE;

    HWND hwnd = CreateWindow(CLASS_NAME, L"Test", style, 50, 50, 100, 100,
                             parent, 0, wc.hInstance, 0);

    if ( !hwnd )
    {
        printf("%d: error %d\n", __LINE__, GetLastError());
        return 0;
    }

    MSG msg;
    while ( GetMessage(&msg, 0, 0, 0) )
        DispatchMessage(&msg);

    return 0;
}

Compile this with the following command (using MSVC command line environment):

cl /EHsc /DUNICODE /D_UNICODE t.cpp user32.lib

Then use Spy++ or some other tool to obtain handle value of any window -- e.g. of Notepad or the browser you're viewing this site in. Let's assume it's 0x00001234. Then run the compiled sample with t.exe 0x1234. Use Ctrl-C to terminate t.exe (or just close the console window).

atzz