Problem with explorer desktop and PAINT messages

[Jesse Allen]

On 4/10/06, Alexandre Julliard <julliard at winehq.org> wrote:
> Jesse Allen <the3dfxdude at gmail.com> writes:
>
> > There is a problem with explorer managing the desktop and the sending of
> > PAINT messages. I've narrowed it down to the following area. In
> > dlls/user/message.c wait_message_reply(), if QS_PAINT are the bits we get,
> > and we call MsgWaitForMultipleObjectsEx, it seems to block the process
> > indefinitely. Should another process be replying here? I decided to
> > make the function return if we get QS_PAINT. Now my app doesn't hang and
> > paints properly. Any ideas what I should be looking for or know?
>
> If we are in wait_message_reply the other process is supposed to
> reply. You should check what message this is, and why it doesn't get
> replied to.
>



This is what the app, Warcraft III.exe is doing
-----
Start of process 0x8:

Creates 16x16 window, WS_POPUP style in thread 0x9, 10024 (Root Window)
ShowWindow 10024
In ShowWindow .... set_active_window
Creates a new thread 0xc
Starts process 0xe
CreateEvent "WARCRAFT_III_OK" and waits on read pipe for event

In thread 0xc:
Creates 500x400 window, WS_EX_TOOLWINDOW, 10026 (Splash Screen)
ShowWindow, 10026
In ShowWindow....hits set_active_window.  Previous active window is
10024, SendMessage WM_NCACTIVATE to 10024 (thread 0x9).  Waits for
reply.

In process 0xe using war3.exe:
Executes some copy protection code
Creates a window 10028 (Game Window -- Not visible)
Waits for process 0x8 to close
----

Both thread 0x9 and thread 0xc are waiting for receiving something
different from each other at the same time. This will never work.
Before explorer managed the desktop, thread 0xc would not send
WM_NCACTIVATE, and when it proceeded, it would cause the
"WARCRAFT_III_OK" event and thread 0x9 would continue normally...
painting etc. The purpose of 0x9 waiting for the event is to see
whether the copy protection threads succeeds normally. If they do not,
it will show a messagebox. But the copy protection threads do succeed,
we are just not passing messages properly at this point.

I tried doing something in set_active_window when getting a window
that is WS_POPUP.  Like returning early with TRUE or FALSE, or just
avoiding the server call or SendMessage WM_NCACTIVATE.  For the most
part the app would no longer hang, but one of three things would
happen, the splash screen would not paint, or the game window would
not paint, or both will paint but the game window would not get input
focus.

The backtrace of thread 0xc at SendMessage is still at
ftp://resnet.dnip.net/ShowWindowProblem.txt

Jesse