user32,x11drv: window maximization issues / sending WM_SIZE

[Juris Smotrovs]

In an attempt to solve bug 4964, I found several issues
where Wine behaves incorrectly (e.g. not sending the messages
it should send) or simply differently (e.g. not sending
messages where Windows sends them, but perhaps there is no
real reason in Wine case to send them) than Windows
during window maximization/restoration.

I wrote a patch correcting these issues and making succeed
10 of the TODO tests in dlls/user/tests/msg.c related with
window maximization/restoration, however it was not accepted,
possibly due to its size and dealing with several issues at once.

Thus, I ask your opinion on a patch correcting the first issue,
the actual reason of bug 4964.

Namely, as specified in documentation, the WM_SIZE message
should be sent when the window is being resized (i.e. when
its width or height is changed) *or* when it changes state
between maximized/minimized/restored.

However, in dlls/user/defwnd.c, DEFWND_HandleWindowPosChanged(...)
Wine looks only for client width and height changes
(signaled by flag SWP_NOCLIENTSIZE). There is another flag,
0x8000 signaling exactly the window state change.

The patch consists of:
1. Introducing a constant for the flag 0x8000, since it is going to
be used in several places.
2. Replacing 0x8000 with the constant in the place where the flag is set.
3. Using the flag in DEFWND_HandleWindowPosChanged to send WM_SIZE
also at state change.

Now, when the WM_SIZE message is sent at maximization, the testcase
WmMaximizeMDIchildInvisibleParentSeq in msg test, written especially
for this problem, proceeds further than before patch, however stucks
to another issue: though being a test marked with TODO, it produces
error messages, because in the message sequence expected default
window procedure messages coincide with actual non-defwinproc messages
(which are expected later), and for such collision the checking for
TODO flag is not written.

Therefore, the patch also
4. Adds checking for TODO flag in the case of the defwinproc collision.

What is your opinion of the patch? Is there anything wrong with it?

Cheers,
Juris