[PATCH] user32: Reimplement TrackMouseEvent.

[Rafał Harabień]

I agree, my use of SendNotifyMessageW was unfortunate for tests but I 
wanted to make sure current thread is not blocked by other thread not 
processing messages. I can change it to SendMessageW.

I uploaded patch v3 with more thread related tests (sleeps + checking 
TME_QUERY result in thread).

I cannot create a test showing that other thread not processing messages 
will break this API because it actually doesn't break TME_QUERY on 
Windows. On MS OS all processing is done in win32k I believe and it has 
full access to thread_info for all threads. In Wine I have two options - 
do tracking in usermode and use internal messages in case of windows 
from different threads/processes, or implement big amount of 
functionality in wineserver which would require much more work. This API 
is all about sending messages (WM_MOUSELEAVE and WM_MOUSEHOVER) so its 
useless for threads which doesn't process messages. Also I believe its 
usually used from WindowProc after receiving WM_MOUSEMOVE (->window 
thread) so complicating it for <5% of use cases is not worth it IMO.

Doing it in wineserver would require to support server-side timers (I 
think we only support client-side) and cursor tracking for child window 
(I think we do it for top-level windows only). Alternatively I could use 
wineserver for getting/saving state only and do all logic in user32 but 
it would require additional communication with wineserver making mouse 
related code slower.

To sum up, I know this is not implemented exactly like in Windows but I 
wanted to make code simple and make as little changes to existing 
architecture as possible. New implementation is passing more tests than 
old one and shouldn't break anything.


W dniu 21.11.2017 o 09:54, Alexandre Julliard pisze:
> Rafał Harabień <rafalh1992 at o2.pl> writes:
>
>> Tests show that TME_QUERY returns valid data if TME_LEAVE or TME_HOVER
>> tracking is active for window in current thread and returns empty data
>> after starting tracking for window from other thread ("track_query(0,
>> NULL, 0)" in test code). It cannot work this way with global variable
>> (as used already in HEAD).
> In fact your test succeeds even with a global variable, because you are
> using SendNotifyMessageW but don't wait for the message to be processed;
> so it's not very convincing. You could add waits, but then I'd like to
> see a test showing that the API doesn't work if the other thread is not
> currently processing messages.
>