Community
Participate
Working Groups
- run the snippet below, which shows an item that starts by answering a width of 100 in its MeasureItem callback - the -10 and +10 buttons at the bottom change this item's desired width - press +10 and note that the example item's width grows, because the width value of subsequent MeasureItem callbacks has been increased by 10 - however, press -10 and note that the example's item's width does not shrink even though the width value of subsequent MeasuteItem callbacks has been reduced by 10 public class MeasureItemTest { static int currentWidth = 100; public static void main(String[] args) { final Display display = new Display(); Shell shell = new Shell(display); shell.setBounds(10,10,200,200); final Table table = new Table(shell, SWT.NONE); table.setBounds(10,10,150,100); new TableItem(table, SWT.NONE).setText("item"); table.addListener(SWT.MeasureItem, new Listener() { public void handleEvent(Event event) { System.out.println("setting event width to: " + currentWidth); event.width = currentWidth; } }); table.addListener(SWT.EraseItem, new Listener() { public void handleEvent(Event event) { System.out.println("-->Received EraseItem with width: " + event.width); event.gc.setForeground(display.getSystemColor(SWT.COLOR_GREEN)); for (int x = event.x; x < event.x + event.width + 10; x += 10) { event.gc.drawLine (x, event.y, x - 15, event.y + event.height); } } }); Button minus10 = new Button(shell, SWT.PUSH); minus10.setBounds(10,130,50,30); minus10.setText("-10"); Button plus10 = new Button(shell, SWT.PUSH); plus10.setBounds(80,130,50,30); plus10.setText("+10"); final Label label = new Label(shell, SWT.NONE); label.setBounds(140,130,50,30); label.setText(String.valueOf(currentWidth)); minus10.addListener(SWT.Selection, new Listener() { public void handleEvent(Event event) { if (currentWidth == 0) return; currentWidth += -10; label.setText(String.valueOf(currentWidth)); table.redraw(); } }); plus10.addListener(SWT.Selection, new Listener() { public void handleEvent(Event event) { currentWidth += 10; label.setText(String.valueOf(currentWidth)); table.redraw(); } }); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }
The same goes for height too (if the appropriate changes are made to Mr. Gayed's code).
Likewise for Tree. Does a separate bug need to be opened for Tree?
It seems that the height problem is caused by code of the form: if (event.height > getItemHeight ()) setItemHeight (event.height); If one subclasses Tree/Table and overrides getItemHeight() you *can* make the items increase and decrease in height. The width case is a completely separate problem.
The height not shrinking is by design, and is enforced on all platforms. I don't remember the history of this, but the root cause was likely a platform limitation.
*** Bug 192770 has been marked as a duplicate of this bug. ***
Currently, trees and tables don't support variable height items. If the height was allowed to decrease, then items required more space would shrink and the tree/table would flash and redraw constantly. There are ways around this. One would be to expose the API Tree/Table.setItemHeight() that programmers could use to shrink the height.
i see. so the intent of "event.height > getItemHeight" was to ensure that all rows have the same height (the max height over all SWT.MeasreItem event.height values). in my use case, all rows_do_ have the same height, but that height is changed when the parent window client area height changes. so if the underlying platforms allow it, i think it should be enabled somehow. IMO exposing Tree/Table.setItemHeight() is actually the more appropriate solution here, since it makes it clear that all rows will have a single new height (rather than a per-item SWT.MeasureItem fix). any chance of this happening soon? Table.setItemHeight currently has package visibility so i'm not sure i can access it without having a private fork of SWT (which i really don't want to do) or playing games with feature patches (which, if it even works, i'm reluctant to do, but won't rule out). the good news is that it sounds like there's no underlying platform restrictions to the desired behavior (changing the table row height when the parent window height changes). is this correct?
> any chance of this happening soon? Not for 3.3. Since API can't normally be released in an x.x.x release, the earliest is 3.4. Sorry about that. However, there will be milestones way before that that might contain the API, assuming we go with it.
cool. thanks for the quick turnaround. if there's any other way i can assist with this item, let me know.
(In reply to comment #6) > There are ways around this. One would be to expose the API > Tree/Table.setItemHeight() that programmers could use to shrink the height. See bug 148039.
Is there a plan to resolve this issue?
What is the status on this bug? Do you have the API working to support this?
This is not currently being investigated. This could happen during 3.7, and probably has a better chance than bug 148039, but is still resource-dependent. The 3.7 plan which outlines where 3.7 efforts will be directed comes out in the fall.
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.
