Bugzilla – Full Text Bug Listing
| Summary: | [Widgets] CoolBar and CoolItem's 'computeSize' seem broken... | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Eric Moffatt <emoffatt> | ||||||
| Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | Felipe Heidrich <eclipse.felipe> | ||||||
| Severity: | normal | ||||||||
| Priority: | P3 | Keywords: | triaged | ||||||
| Version: | 3.2 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | stalebug | ||||||||
| Attachments: |
|
||||||||
|
Description
Eric Moffatt
BTW, 'Border' is my own control that always reports the size given in the constructor in its computeSize... Please, give me a SWT snippet that shows the problem. Thanks. Created attachment 46103 [details]
Snippet to demonstrate the 'computeSize' error
Place a debug breakpoint at the 'shell.pack()' and run the snippet.
Look at the various values returned from the compute size calls.
Perhaps I'm using the calls incorrectly (i.e. I haven't called 'ci.setPreferredSize()'...) or perhaps I've misunderstood the meaning of 'computeSize'...
Hi Eric, that is not how to do it. CoolItem don't call computeSize in the control you set using setControl, you need to use setSize, setMinimumSize and setPreferredSize in CoolItem. use the following code after instering all coolitems to your coolBar:
//set cool items size
CoolItem[] coolItems = coolBar.getItems();
for (int i = 0; i < coolItems.length; i++) {
CoolItem item = coolItems[i];
Control control = item.getControl();
Point size = control.computeSize(SWT.DEFAULT, SWT.DEFAULT);
item.setMinimumSize(size);
size = item.computeSize(size.x, size.y);
item.setPreferredSize(size);
item.setSize(size);
}
Created attachment 46192 [details]
Updated version showing the error more accurately
Sorry Filipe, I was a bit unclear in my original description...the new attachment has in-line comments but I'll give some idea of what I'm trying to do.
I already have the 'standard' pattern but my use case is a little more complicated because the CoolBar's size is not static:
I'm trying to use CoolBars to wrap 'trim' elements in the workbench (Fast view bar, progress bar, status line...). One of the features of trim is that you can define it to use 'extra' space (like the GridLayout's 'GRAB_EXCESS' handling).
The problem is that if, for example, the trim is supposed to stretch to fill up the trim area then the layout will resize the CoolBar to take up the correct amount of space but ensures that it's never less than its preferred size.
If you place the breakpoint in the same place and look at the values for 'eciSize' and 'ecbSize' you should see the following problems:
'eciSize' is (48,32)...the code is -clearly- broken...I've set the preferred size to (116,100) which is clearly what this should be returning according to the javadoc.
'ecbSize' is a -mixture- of the CI's preferred size (horizontal) and the CB's current size (vertically). Surely if a CoolBar has a single CoolItem whose preferred size is (116, 100) then this would be the expected answer.
Because we now have a 'default' preferred height of 150 for 'ecbSize' the layout can -never- find its true preferred 'height' anymore...
I've been forced into hacking up a Composite that has a Layout that does what it thinks is right but I'd much prefer not to go this route for both performance and because I'm concerned about platform-specific issues that may arise (i.e. while my current code works on WinXP the chevrons get clipped on Win2K systems). I'm happy enough to define the CI's preferred size during its construction but, once it's set I expect that the 'computeSize' will work as doc'd.
Re-opening...with a new patch that should better explain the issue. 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. |