Dialog created within a thread

  • Thread starter Thread starter Victor
  • Start date Start date
V

Victor

Hi everybody,

could anybody kindly give me a clue in dealing with a following problem
:

I create a modeless dialog by means of CreateDialogIndirect(). The call
executes within a thread and the returned HWND is assigned to a global
variable. The dialog appears and can be properly operated, but it
exists only this long as the thread where the call happens remains
alive. On closing the thread the dialog disappears the same moment.
I would like to keep it independent on the thread, though its creation
(and displaying) should be initiated by the logic flow of the thread.

My development tool is VS 2005 C++ under WinXP.

How can I achieve this goal?

Thanks in advance

Victor
 
Victor said:
I create a modeless dialog by means of CreateDialogIndirect(). The call
executes within a thread and the returned HWND is assigned to a global
variable. The dialog appears and can be properly operated, but it
exists only this long as the thread where the call happens remains
alive. On closing the thread the dialog disappears the same moment.
I would like to keep it independent on the thread, though its creation
(and displaying) should be initiated by the logic flow of the thread.
Click to expand...

That's not possible. The lifetime of windows and the lifetime of the threads
that own them are inextricably bound.
 
That's not possible. The lifetime of windows and the lifetime of the threads
that own them are inextricably bound.
Click to expand...

Thank you, William.

Could you however comment it a little bit more?

I believe it's not this straight and forward in my case.
The thread call for CreateDialogIndirect() looks like this :

dlgRoute =
CreateDialogIndirect(instance,(LPCDLGTEMPLATE)hgbl,hwnd,(DLGPROC)routeProc);

Here are

dlgRoute HWND global varialbe
instance HINSTANCE global variable, handle from the
InitInstance() call during startup of the application
hgbl HGLOBAL local variable of the thread
hwnd HWND global variable, returned by the
CreateWindow() call from within the mentioned InitInstance() thus being
a handle to the top window.

Does it mean that the owner of the dialog must be the app top window?
According to the MSDN, the parameter 'hwnd' specifies 'Handle to the
window that owns the dialog box'. Is it not my case? And this owner
happily continues to exist after the thread ends up...

Victor
 
Victor said:
Thank you, William.

Could you however comment it a little bit more?

I believe it's not this straight and forward in my case.
The thread call for CreateDialogIndirect() looks like this :

dlgRoute =
CreateDialogIndirect(instance,(LPCDLGTEMPLATE)hgbl,hwnd,(DLGPROC)routeProc);

Here are

dlgRoute HWND global varialbe
instance HINSTANCE global variable, handle from the
InitInstance() call during startup of the application
hgbl HGLOBAL local variable of the thread
hwnd HWND global variable, returned by the
CreateWindow() call from within the mentioned InitInstance() thus being
a handle to the top window.

Does it mean that the owner of the dialog must be the app top window?
According to the MSDN, the parameter 'hwnd' specifies 'Handle to the
window that owns the dialog box'. Is it not my case? And this owner
happily continues to exist after the thread ends up...
Click to expand...

There is a requirement throughout Windows - every version - that a window
can only be accessed by the thread that created it. Any attempt to access
an HWND from another thread results in a SendMessage to the owning thread,
which must handle the message before the requesting thread can un-block.
This is a common source of deadlocks when windows are owned by multiple
threads.

If your worker thread needs to terminate before the lifetime of the dialog
is completed, then you need to create the dialog in another thread - one
that outlives the dialog.

It's usually best to have all of the windows created by the main thread, but
it's not required.

-cd
 
Victor said:
Thank you, William.
Click to expand...

You are welcome.
Could you however comment it a little bit more?
Click to expand...

I see that Carl has already explained the issue. To add a little more
information, you have to realize that the message queue for a window is
attached to the thread that owns it. When the thread dies, the queue is
destroyed because there is _no_ longer any way in which a _posted_ message
could be removed from it. In fact, I found (in an application of mine which
had a bug that caused a premature thread death) that the window manager
would summarily remove an "orphaned" window from the screen without the
usual flurry of messages, e.g. WM_CLOSE, WM_DESTROY, WM_NCDESTROY etc.
 
Back
Top