http://bugs.winehq.org/show_bug.cgi?id=17654
Summary: Edit control on toolbar behaves badly Product: Wine Version: 1.1.16 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: comctl32 AssignedTo: wine-bugs@winehq.org ReportedBy: tarasov.igor@gmail.com
Created an attachment (id=19839) --> (http://bugs.winehq.org/attachment.cgi?id=19839) +message,+toolbar,+edit logs for both native and builtin comctl32 on wine-1.1.16
Let's start with a screenshot: http://www.polosatus.ru/wine/lefttoolbar.sidebyside.png
On this screenshot you can ignore red numbers, they are related to bug #12553. The interesting part is edit control, and even more interesting is the most right button. When running with native comctl32 (bottom image) as you can see the button is positioned to the right from the edit control. But with builtin comctl32 (top image) the button is positioned below the edit control. Also, there is 2 px gap between buttons (supposedly that's what toolbar control thinks about edit width).
This is the first strange thing.
The second one is displayed on this screenshot: http://www.polosatus.ru/wine/editbug2.sidebyside.png
Here native comctl32 shows combobox 100% toolbar wide (and without the dropdown button), and no edit control. Builtin one shows combobox not in full toolbar size and shows dropdown button. But that's not big problem. The problem is that edit control is out there, while it shouldn't.
Related to this bug here is what is there in the log: There is WM_WINDOWPOSCHANGING sent to the edit control which happens with both native and builtin comctl. But native then also sends WM_WINDOWPOSCHANGED and WM_MOVE and really moves edit item out of toolbar visible area (somewhere to the right).
P.S: The application is Watchtower Library.
http://bugs.winehq.org/show_bug.cgi?id=17654
--- Comment #1 from Igor Tarasov tarasov.igor@gmail.com 2009-03-10 09:34:09 --- So, I've figured that. Some story: there is a comment in toolbar.c:
/* UNDOCUMENTED: If a separator has a non zero bitmap index, */ /* it is the actual width of the separator. This is used for */ /* custom controls in toolbars. */ /* */
This is incorrect. I am not sure what the correct behavior is exactly, but if there was TOOLBAR_SetButtonInfoW call updating button size (cx) then native comctl changes separator's width. Builtin ignores this value.
Way to reproduce with control spy: Open toolbar.exe. Send two messages one by one: Firstly change button into separator:
MSG (TB_SETBUTTONINFO,2, TBBUTTONINFO(tbbisize,8,0,0,0,1,0,0,"string",127))
Second, change that button (now separator) size:
MSG (TB_SETBUTTONINFO,2, TBBUTTONINFO(tbbisize,64,0,0,0,0,40,0,"string",127))
Compare with native comctl behavior.
http://bugs.winehq.org/show_bug.cgi?id=17654
nille newilkman@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #2 from nille newilkman@yahoo.com 2009-03-10 13:06:17 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=17654
--- Comment #3 from Igor Tarasov tarasov.igor@gmail.com 2009-03-11 06:49:50 --- Here is what I've found:
"Adding controls to a toolbar has been something people have wanted to do since the first common toolbar control, back when Win95 was released, and the standard practice for this works something like this:
* Change the placeholder button to be a separator, as thanks to a design quirk, the width of a separator can be changed. * Change the width of the separator to match that of the control you want to create. * Create the control using the separator button rect as the size, with the toolbar as the control's parent.
This has worked fine for various flavour framework apps for many years"
http://www.codeproject.com/KB/wtl/CToolBarHelper.aspx?display=Print (there is some code for doing this).
Seems that MFC also uses this technique (the application that was initally referenced in this bug is MFC-based one). MFC example: http://www.ucancode.net/Visual_C_Control/Place-Combo-Edit-Box-Progress-Contr...
Could anybody of developers, please, say at least something on this bug?
http://bugs.winehq.org/show_bug.cgi?id=17654
--- Comment #4 from Igor Tarasov tarasov.igor@gmail.com 2009-03-13 13:56:47 --- Here are more results:
After some controlspy testing I can say that I was not able to reproduce expected behavior on native comctl. That is, wine now does it all wrong.
As I've told, wine thinks that there is some kind of not documented feature (see above) that when you set bitmap index for separator on a toolbar it affects separator's width. But this just does not work with native comctl32!
To see this, all you have to do is to open Toolbar.exe and send the following: MSG (TB_SETBUTTONINFO, 0, TBBUTTONINFO(tbbisize, TBIF_STYLE | TBIF_IMAGE,0,40,0,1,0,0,"string",127))
If we agree with asumption that there is such undocumented feature, button with id = 0 should be converted into separator with 40 px width. But, this just does not happen! That is button does change into separator, but it has default width. I've been testing it out a lot with various values, creting/recreating buttons etc. But native comctl32 has NEVER changed separator width based on bitmap index.
On the other hand, it does respond very well when you change button's size: MSG (TB_SETBUTTONINFO, 0, TBBUTTONINFO(tbbisize, TBIF_STYLE | TBIF_SIZE,0,0,0,1,40,0,"string",127))
But builtin comctl32 does everything inside out: it ignores TBIF_SIZE and responds to TBIF_IMAGE.
And just now I've found this MSDN article: http://msdn.microsoft.com/en-us/library/477kf668(VS.80).aspx
It's an MFC refernce for CToolBar::SetButtonInfo. And there you can find the following remark: "For separators, which have the style TBBS_SEPARATOR, this function sets the separator's width in pixels to the value stored in iImage."
So, this is not WinAPI undocumented feature. I suppose that somebody have just confused APIs.
http://bugs.winehq.org/show_bug.cgi?id=17654
--- Comment #5 from Igor Tarasov tarasov.igor@gmail.com 2009-03-15 18:15:57 --- Created an attachment (id=19976) --> (http://bugs.winehq.org/attachment.cgi?id=19976) cumulative patch for toolbar separators
So, here is the patch. It fixes the following errors:
1. Ignoring setting separator width. 2. Incorrect treating of iBitmap for separators. 3. CCS_VERT toolbars were having horizontal separators. 4. It fixes both problems from this bug.
In details, what was finally found out:
1. When new button is being inserted, iBitmap stands for it's size. This is documented: http://msdn.microsoft.com/en-us/library/bb760476(VS.85).aspx
2. Updating iButton for separator on native comctl get weird results. All buttons located after this separator get their bitmaps uncentered, and sometimes even get out of the button. I suppose that this is not a feature, but a bug. To reproduce, do the following with Control Spy's Toolbar.exe:
MSG (TB_SETBUTTONINFO, 0, TBBUTTONINFO(tbbisize,1,0,0,0,0,0,0,"string",127))
Note: toolbar won't update. Just make it redraw by moving some window over it, or by moving Toolbar.exe window partly out of screen edges and back.
If you send TB_AUTOSIZE, it would put button images to new button locations. This way you can really adjust separator width but only in range from 0 to 14 px. Try playing with second 0 in TBBUTTONINFO structure.
One of my assumptions is that this behavior might be result of running wine. But I don't have Windows box here, so I can't test. If you can, please let me know about the results.
3. Separators flip vertical on CCS_VERT, not on BTNS_DROPDOWN.
4. I wasn't able to make toolbar behave as vertical with builtin comctl. With native just change toolbar's style to CCS_VERT, and you'll see the difference. But it seems to be another bug.
5. Interesting thing: second problem described in the first comment is partly due to incorrect wine + native comctl32 behavoir. In windows you see something like this: http://polosatus.ru/wine/toolbarcombo.png
But wine with native comctl32 displays combobox full toolbar wide and without the dropdown button (see screenshot in first comment). But builtin comctl with this patch displays that toolbar as it should. So, that's the first time I've met native comctl32 behaving wrong.
http://bugs.winehq.org/show_bug.cgi?id=17654
--- Comment #6 from Dmitry Timoshkov dmitry@codeweavers.com 2009-03-16 01:46:20 --- Igor, it looks like you are much more confident with current Wine code and intended behaviour than anybody else, so *you* are the developer to consult with :-) Please feel free to send your patch in chunks with (if possible) appropriate test cases. Thanks!
http://bugs.winehq.org/show_bug.cgi?id=17654
Igor Tarasov tarasov.igor@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #7 from Igor Tarasov tarasov.igor@gmail.com 2009-04-04 23:25:33 --- Patches committed, marking as fixed.
http://bugs.winehq.org/show_bug.cgi?id=17654
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #8 from Alexandre Julliard julliard@winehq.org 2009-04-10 11:23:02 --- Closing bugs fixed in 1.1.19.
-
wine-bugs＠winehq.org