Community
Participate
Working Groups
Build: 20020529 If you select "Lock the ToolBars", the coolbar items should all shift to the left a little bit and give up the space that the coolbar handle used.
Lynne, I suspect this has to get pushed down to SWT, but wanted to run it by you first.
Reassigning to SWT.
I've seen other windows apps do this. This is lower priority than the other CoolBar issues however.
It can be fix by setting the cxHeader of each band when locking the coolbar. Jed, can you point an application where this behavior occurs ? Anyway, if I fix this PR it will fix 19137 and 14330 as well.
Right click in an Eclipse 0910 toolbar and select "Lock the Toobars".
Sorry, I meant: Point me a application where the behavior you want (= coolbar give up space when is locked) occurs. Something like IE, MS Word, whatever. I don't know (or I don't know how) any other application where the coolbar can be locked.
In Windows XP, you can lock/unlock the toolbar. If you have the Quick Launch toobar visible and lock the toolbar, the little textured area that you grab to move the toolbar around disappears, and the toolbar becomes a little smaller.
Ok, thank you. I think SWT should do the same then.
Created attachment 2932 [details] setLocked(boolean lock) fix I fixed this for my own app and am submitting it here. In my experience toggling the cxHeader on each band back and forth between 0 and 9(13?) provided unexpected results in the rebar. IIRC the bands would keep moving left each time I toggled the locked flag. The proposed fix is for the win32 version. Deleting and re-inserting the bands seemed like the quickest and easiest way to go about fixing it. As far as I can tell it shouldn't affect the existing CoolItem references as they always refer to themselves by using parent.indexOf(this), which does a id to index lookup. The ids are preserved in the reinsertion.
Yes, changing the cxHeader leads to an unexpected behavior and that is way I never release the code leaving this bug open. I believe your code works, but I'm afraid of that re-creanting all the RebarBands, it may cause another unexpected behavior. I wonder if there is no another way to force the OS to recompute the cxHeader. I will have to do more test before go ahead and release your fix.
Will this be released for RC3?
Approved for RC3 by Veronika.
Approved by Mike for RC3.
I can't release this. The process used in here to force the Coolbar to recompute the cxHeader will not only recompute the cxHeader but will relayout the whole widget. Cause of the bug#34923, situation where the coolbar comes up if the wrong height, toggling the lock (with the new code) will cause the widget to relayout to the correct height, what will fire resize listeners on the UI side and cause the Coolbar to resize to the wrong height once again. It will lead a quite bad jumpiness on the Coolbar. This bug is block by 34923.
The process to lock and unlock the Coolbar only forces a relayout when an XP manifest is used. The purpose of the setRedraw(false/true) calls is to prevent this jumping/resizing sort of behavior, however the Coolbar does not allow the WM_SETREDRAW calls to go through if the comctl32.dll version is 6. Allowing the widget to process the WM_SETREDRAW messages while in the setLocked method will rectify the behavior.
You are right Rob, but Coolbar has quite a few hacks in the WM_SETREDRAW. I think it's dangerous the touch in there when we are so close of releasing 2.1.
*** Bug 55834 has been marked as a duplicate of this bug. ***
Your bug has been moved to triage, visit http://www.eclipse.org/swt/triage.php for more info.
This is a one-off bulk update. (The last one in the triage migration). Moving bugs from swt-triaged@eclipse to platform-swt-inbox@eclipse.org and adding "triaged" keyword as per new triage process: https://wiki.eclipse.org/SWT/Devel/Triage See Bug 518478 for details. Tag for notification/mail filters: @TriageBulkUpdate
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
