
modeless dialog in ATL DLL
Hi,
I have a modeless chat dialog in an ATL DLL. The parent of the dialog is an
invisible window, and the parent of that is
CWnd::FromHandle(GetDesktopWindow()). This was done so that a button for
the dialog would not appear in the taskbar.
When a client connects to my app (using DCOM), one of these dialogs is
created on each end of the connection. The dialogs are hidden at first, but
are shown when the user clicks a toolbar button or when the other side sends
a chat message. In Windows 98 everything works fine. Unfortunately, if the
server is running Windows 2000 then the dialog doesn't show up properly
either way.
I have discovered that Windows 2000 creates a new thread when the client
connects to the user. This doesn't happen in 98--everything is in one
thread. The new thread is the thread that creates the chat dialog.
However, the handler for the toolbar button that pops up the chat dialog is
in the main thread of the app. I have traced through this handler down to
CWnd::ShowWindow(), and the application hangs when it calls ::ShowWindow().
I overrode ShowWindow in my dialog to just set a flag so that
CWnd::ShowWindow() would be called later when the new thread was running
instead of the main thread. This isn't really a desirable solution, I was
just trying to confirm that that was causing a problem. Sure enough, it
started behaving the same as when the client sends a message across
(described below).
When the client sends a message to the Windows 2000 server, the chat dialog
is popping up. However, none of the controls are visible. Also, the mouse
cursor turns to an hourglass when it is positioned over the dialog. The
rest of the app seems to function normally. If the client disconnects, the
chat dialog is destroyed normally. I tried calling UpdateWindow on the
dialog after ShowWindow(). This caused the controls to appear, but the
hourglass cursor remained and I was unable to use any of the controls in the
dialog.
Can anybody help with any of these problems? The ideal solution would be to
prevent the extra thread from getting created, so that the app would work
just as it does in Windows 98. But I can live with the thread if I can get
this dialog to work right.
Thanks,
David St. Hilaire