user32, x11drv: patch to send WM_SIZE at window state change (bug 4964)

[Juris Smotrovs]

Alexandre Julliard wrote:

>>@@ -1435,9 +1435,19 @@
>> 		     "%s: in msg 0x%04x expecting lParam 0x%lx got 0x%lx\n",
>> 		     context, expected->message, expected->lParam, actual->lParam);
>>             }
>>-	    ok_( file, line) ((expected->flags & defwinproc) == (actual->flags & defwinproc),
>>-		"%s: the msg 0x%04x should %shave been sent by DefWindowProc\n",
>>-		context, expected->message, (expected->flags & defwinproc) ? "" : "NOT ");
>>+	    if ((expected->flags & defwinproc) != (actual->flags & defwinproc) && todo)
>>+	    {
>>+		    todo_wine {
>>+                        failcount ++;
>>+                        ok_( file, line) (FALSE,
>>+			    "%s: in msg 0x%04x expecting lParam 0x%lx got 0x%lx\n",
>>+			    context, expected->message, expected->lParam, actual->lParam);
>>+		    }
>>+	    }
>>+	    else
>>+	        ok_( file, line) ((expected->flags & defwinproc) == (actual->flags & defwinproc),
>>+		    "%s: the msg 0x%04x should %shave been sent by DefWindowProc\n",
>>+		    context, expected->message, (expected->flags & defwinproc) ? "" : "NOT ");
> 
> The problem is that this will cause tests that currently succeed to be
> turned back into todos. It would be better to do the changes in a way
> that doesn't break existing tests.

Not exactly. If a test currently succeeds (todo == FALSE),
then the else branch will execute, and the else branch is
exactly as before the patch. So nothing will change for successful tests.

Anyway, if you are wary about changes affecting all tests,
I will prepare another patch, simply disabling the
particular (todo == TRUE) test causing the problem,
with a FIXME comment.

This test is unsuccessful both before and after the patch,
simply because of currently not checking for todo flag
at defwinproc mismatch, it gets reported as test failing the
whole msg suite.

The defwinproc mismatch itself appears
because, after solving the WM_SIZE issue, this message --
correctly -- is sent, so the actual message queue shifts
relative to the expected message queue, and -- due to
some messages still missing -- three expected defwinproc
messages coincide with three actual non-defwinproc messages
which are expected later-on. Thus this failure is actually
not about messages sent from incorrect place, but simply
about missing messages which is a very typical failure
among the todo tests.

Cheers,
Juris Smotrovs

>