user32: After handling an internal message give a chance to real message to arrive.

[Dmitry Timoshkov]

Alexandre Julliard <julliard at winehq.org> wrote:

> >> >> If you can avoid internal messages that's certainly good, but yes, I'd
> >> >> like to see more tests. In particular, for SetWindowPos you'd want to
> >> >> test using separate thread inputs, and how that work with changing the
> >> >> active window etc. Also SWP_ASYNCWINDOWPOS should be tested, from the
> >> >> docs it sounds very much like it needs an internal message.
> >> >
> >> > It would be helpful to clarify status of the already sent patches first,
> >> > after that I'll see waht could be done next.
> >> 
> >> I'm hoping you can consolidate this into a single series of tests that
> >> focuses on the problematic area.
> >
> > Already sent tests already do test the cases which I consider as a most
> > likely source of the problem. There is no other theories on my part so
> > far, there is nothing to consolidate.
> 
> They may be enough to show that there's a problem, but they are not
> sufficient to demonstrate that your proposed solution is correct. In
> order to do that, you'll need to test the things I mentioned above.

I understand that the patch that removes WM_WINE_SETWINDOWPOS message
probably needs more tests, it's already in the pending state, I'm asking
about the tests that are waiting in the queue. First thing I'm trying to
do is understand where exactly the source of the problem is, and the tests
I sent exersize the suspected things one by one. There is no point in testing
something that clearly doesn't happen with the application I have here (like
SWP_ASYNCWINDOWPOS, or separate thread inputs), and spending my time writing
tests for that things won't happen until there is a clear understanding
what is going on and that the proposed solution needs to cope with unrelated
things.

-- 
Dmitry.