Bugzilla – Full Text Bug Listing
| Summary: | [Widgets] CoolBar - when locked and add new items, new items not locked | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Lynne Kues <lynne_kues> | ||||
| Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Felipe Heidrich <eclipse.felipe> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | grant_gayed, lynne_kues, michaelvanmeekeren, n.a.edgar | ||||
| Version: | 2.0 | Keywords: | triaged | ||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 2000 | ||||||
| Whiteboard: | stalebug | ||||||
| Bug Depends on: | 18267 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Lynne Kues
Created attachment 683 [details]
test case
Carolyn, the test case is based on example code you sent. I didn't include the *.gifs for the test case. For now, do you mind working around this by unlocking the coolbar before adding the item, and then locking it again? I tried putting in the 'correct' fix, and it works, but it exposes a computeSize problem that I don't know how to work around. The problem is that when the application creates a cool item in the 'locked' state and then sends computeSize, the cool item (correctly) answers its size without the gripper (a difference of 9 pixels, fyi). Then, the application uses that computeSize to set the preferredSize and Size. When the coolbar is subsequently unlocked, that particular item thinks it isn't wide enough to show its griper, so it acts as if it is still locked. (It isn't, because I can double-click on some other item which seems to change all the item sizes, and then the new item shows its gripper.) Anyhow, if you are in a hurry for this fix, please try the workaround and let me know if it flashes (it seems ok in my simple example). It may take me a while to figure out how to fix this completely. Calling redraw/layout doesn't help, and faking the answer to computeSize doesn't help. I can work around, but I had to do something weird. I tried to put in this code around the code that updates the CoolBar boolean lockState = coolBar.getLocked(); if (lockState) coolBar.setLocked(false); // do work to update coolbar if (lockState) coolBar.setLocked(true); However, this code does NOT work if the coolbar does not have any items. For some reason, if no items have been added to the CoolBar its locked state is TRUE even if you explicitly set it to false when you create the coolbar. So my code now looks like this and it seems to work, but it is additional odd behavior. boolean lockState = coolBar.getLocked() && (coolBar.getItems().length > 0); if (lockState) coolBar.setLocked(false); // do work to update coolbar if (lockState) coolBar.setLocked(true); Fixed the last little problem. CoolBar.getLocked() is now correct for CoolBars with no items. If you say setLocked(true), it will answer "locked", and if you don't ever lock the coolbar, it will say "unlocked". Had to keep state in the coolbar to do this, but that's the price we pay for inventing the "lock the entire coolbar" API. Still trying to figure out what the best thing to do about the other problem is. If the compute size problem is ever fixed, then this is the code that should
have gone into createItem:
if (locked) {
rbBand.fStyle |= OS.RBBS_NOGRIPPER;
}
after the rest of the rbBand.fStyle setting code.
If I fix the PR 18267 this problem that Carls refers as a computeSize bug no longer exist. So I can add the fix to createItem and then close this PR. Lynne, 18267 is a feature request, please take a look at and see if the behavior proposed on that is ok for you. It will fix 19137 as well. The proposed behavior for 18267 seems okay to me - it's what IE does and is apparently what people expect to happen. *** Bug 54676 has been marked as a duplicate of this bug. *** *** Bug 59522 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. |