Community
Participate
Working Groups
[I20070418-1012, Windows XP] I'll attach a snippet. Note that the blue background for the selection does not go all the way to the right initially. Upon resizing the shell, the right column grows to take up the extra space.
Created attachment 64886 [details] snippet
Ok. I found the problem but I don't have an idea how to work around this. The problem is when the layout is called: computeTrim(...) { Point preferredSize = computeTableTreeSize(scrollable, area.width, area.height); System.err.println("PREFERRED-SIZE: " + preferredSize); //$NON-NLS-1$ System.err.println("AREA: " + area); //$NON-NLS-1$ } This returns: PREFERRED-SIZE: Point {309, 383} AREA: Rectangle {0, 0, 292, 366} This means for us that we thing we need that we think the table needs to have scrollbars or at least that we need to check for this and when the table is layouted the first time the vBar.isVisible() returns true. When resizing the the preferred size is still returning nearly the same figures but in constrats to before vBar.isVisible(). I've now removed this whole code and the layout still works (only tested on WinXP) currently. There's only one special case visible if you resize the shell slowly you'll notice that when the shell is exactly the size the table needs to display the content without a vertical scrollbar but the scrollbar the client-area still thinks a scrollbar is needed. So we have 2 possibilities: a) make table#computeSize() work correctly (=> depends on SWT) b) remove the code as the patch I'll attach and live with the problem described below
Created attachment 64935 [details] patch to test
One more note on this: when you call shell.setSize(300, 400); before creating the table there's no space left on the right.
The issues is not reproduceable on Linux-GTK, but the patch doesn't harm Linux-GTK so it's save here to remove the code.
even the exception stated for win32 in comment #4 is not happening on Linux-Gtk
this patch produces problems on OSX where a vertical scrollbar is shown in Snippet16 and Snippet17. Question is now should we add a WIN32 check or an MacOSX check. One for MacOSX seems to be better because MacOSX needs much more calculation as it looks now.
Boris what's your feeling here, do you go along with me adding a MacOSX check? I'd like to get this in for M7 so I need to fix it tomorrow.
need to delay to RC2 but I didn't had time to do any work this week
Created attachment 67651 [details] Fix for the problem I discovered that the same reported for WinXP is also true for MacOSX under certain circumstances. The misbehaviour from the old patch on OSX was because I also removed the relayouting. Boris could you test on Gtk, WinXP and Vista? The current layout-snippets and your test-snippet.
Looks good on Windows XP and Vista/Win32.
Looks good on GTK. However, I don't think we should increase the risk for RC1 by putting this in now, so I'm leaving the RC2 target milestone.
+1
Released >= 20070524
As of RC2, a tree that has a vertical scroll bar now also shows a horizontal scroll bar initially. When resizing the enclosing shell, the horizontal scroll disappears. Could this have sth to do with the patch for this bug? Before RC2, a tree with a TreeColumnLayout did not show this behaviour.
What OS?
Oops, sorry, forgot to mention.. Win XP.
Need to take a look.
Sorry, I tried to reproduce with Snippet027 from our collection and the one attached to the bug from Boris but was not able to reproduce please provide a snippet representing this behaviour.
In I20070525-1350. Karsten please open a new bug if you have snippet to reproduce this behaviour and CC me.
I have a similar problem. TableColumnLayout layouts the table correctly the very first time but when I decrease the width of its parent composite, it doesn't respect the minimum sizes of ColumnPixelData instances, it doesn't decrease enough the size of the resizable column, it displays the horizontal scroll bar and it hides the last column. When I disable the scrolling (SWT.NO_SCROLL), the last column is still hidden.
