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@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.