[1/2] comctl32/tests: Added tests for mouse events handling (try 3)

Daniel Jelinski djelinski1 at gmail.com
Sun Apr 15 05:38:02 CDT 2012


Hello,
I see that my patch hasn't been accepted yet. Well if some explanation
could help it through, here goes:
Bug 19222 makes using MS SQL Server management studio a pain. The
application displays database structure in a tree view, and most
actions are executed from a context menu displayed by right-clicking
on a relevant position in the tree view. Unfortunately Wine suffers
from a bug - right click displays the menu, but selecting any option
from the menu causes another menu to be displayed at the current mouse
position. Selecting an option from this second menu works as expected.
Also opening the popup menu by pressing context menu key on the
keyboard works properly.
The usual suspect in such cases is that incorrect messages are sent,
or messages are sent in incorrect order. I tried to run the
application with native comctl, but unfortunately it refused to work -
probably comctl version 6.0 is required, while winetricks installs
version 5.80. So I created my own application in Delphi. It dispayed
the same problem with builtin comctl and worked correctly with native.
Then I tested it with WINEDEBUG=+message. The outstanding differences
were:
- on native comctl treeview sent two messages to the main window -
first WM_NOTIFY (NM_RCLICK) and then WM_CONTEXTMENU
- on builtin comctl treeview sent first WM_CONTEXTMENU to self, which
then got propagated to main window, and then WM_NOTIFY(NM_RCLICK).
There was something peculiar - WM_RBUTTONUP never appeared in the
logs. I checked to see why and found a function TREEVIEW_TrackMouse.
This function is called by WM_RBUTTONDOWN handler and it captures all
events from the message queue until it finds either WM_RBUTTONUP or
WM_MOUSEMOVE with coordinates sufficiently far from the origin of the
click. There was also a comment stating that "This is quite unusual
piece of code, but that's how it's implemented in Windows.". Given the
absence of WM_RBUTTONUP in message logs I consider this assertion to
be true.
With this knowledge I proceeded to write tests. I wanted to emulate
right button down/up sequence. I couldn't send both messages by
SendMessage, because SendMessage sends messages directly to the window
procedure, and WM_RBUTTONUP has to be delivered by message queue. I
also didn't want to push both messages to the queue - this would net
me several more irrelevant messages like WM_PAINT and could cause
failures if someone moved the (physical) mouse during the test. This
is why I chose to post WM_RBUTTONUP and then send WM_RBUTTONDOWN.
Later, thanks to our friendly bot Marvin, I found out that older
versions of comctl sent WM_PAINT messages during the button
down/button up sequence, bypassing the message queue. It took me
several tries to find out which messages are sent, but now the patch
works correctly on all tested comctl versions.
Then I corrected Wine to pass the tests. I tested both applications
(Microsoft's and mine) to see if they work correctly when the correct
messages are sent. They do.

If there is anything else I can do to help this patch get accepted,
let me know. I'd like to have a clean git origin before I start fixing
other treeview problems.
Thanks for your patience,
Daniel



More information about the wine-devel mailing list