Dusan Vujosevic wrote:
Hi,
I am having a problem with the way toolbar.c was modified between revisions 1.107 & 1.108. My application (Signlab) pops flyout toolbars that stay around until they lose focus. The parent toolbar receives a 'TBN_DROPDOWN' message when someone clicks on one of its flyout buttons (button style: TBSTYLE_DROPDOWN). It creates a flyout at that point.
With revision 1.108 of toolbar.c in Wine the parent toolbar also receives an WN_COMMAND after TBN_DROPDOWN message which causes Wine (rightly so) to send an WM_SETFOCUS (and WM_ACTIVATE). That causes the parent to regain focus and kills the flyout. The line that sends the WN_COMMAND is in toolbar.c at line 4540 (TOOLBAR_LButtonUp() function): SendMessageA (infoPtr->hwndNotify, WM_COMMAND, MAKEWPARAM(infoPtr->buttons[nHit].idCommand, 0), (LPARAM)hwnd); In revision 1.107 it used to be:
if (bSendMessage) SendMessageA (infoPtr->hwndNotify, WM_COMMAND, MAKEWPARAM(btnPtr->idCommand, 0), (LPARAM)hwnd);
And that worked fine because it would never send WM_COMMAND for a flyout button. Note that WinXP (that's where I tested) doesn't send WM_COMMAND after TBN_DROPDOWN has been handled. I would like to suggest revert that line back to 1.106 because it is the correct way.
It is not "the correct way", since I have tested it with control spy under WinNT and Wine. That is not to say that my patch is correct either, but it fixes two different applications I have and in my mind is closer to the correct way. There may well be some conditions under which the message should not be sent, but the previous way was not correct. So I guess Alexandre gets to pick which incorrect version to use ;)
And there is more going on in your app, because the flying toolbars also disappear when the mouse is simply slid over them, without clicking. This behavior is not there under Windows, and has nothing to do with the ButtonUp change I made. The two may not be related, but I cannot help thinking they are. Unfortunately, I was not able to get a spy program to work with your app in windows, so I have not been able to figure out what messages should really be sent, and when. Certainly a common problem is that a fix in one area exposes a problem elsewhere, and that possibly is what happened here.