Rafał Harabień rafalh1992@o2.pl writes:
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.
It may be that we don't want to do it the same way as Windows, but I don't think we can decide that until we know how it's supposed to behave, which means writing more tests. If it turns out that the proper behavior is too hard to do right, we can then decide to leave the tests as todo for now.