Community
Participate
Working Groups
Run the following example. Notice that there is an area along the right side of the table that is blank (the grid lines to not run through it). If you uncomment the table.redraw() call, this area is correctly drawn. There may be something to do with the scrollbar happening here. public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); shell.setLayout(new GridLayout()); final Table table = new Table(shell, SWT.BORDER); table.setLayoutData(new GridData(GridData.FILL_BOTH)); table.setLinesVisible(true); table.setHeaderVisible(true); final int columnCount = 4; for (int i = 0; i < columnCount; i++) { TableColumn column = new TableColumn(table, SWT.NONE); column.setText("Column "+i); } final Listener[] listener = new Listener[1]; listener[0] = new Listener() { public void handleEvent(Event e) { table.removeListener(SWT.Resize, listener[0]); Rectangle rect = table.getClientArea(); TableColumn[] columns = table.getColumns(); table.setRedraw(false); for (int i = 0; i < columns.length; i++) { columns[i].setWidth(rect.width / columns.length); } table.setRedraw(true); // bug in table, redraw should not be neccessary //table.redraw(); } }; table.addListener(SWT.Resize, listener[0]); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } NOTES:
PRODUCT VERSION: 0.125 Windows 2000
Hi, I think this bug is similar to what I found, but I think the problem is not related to scrolling (which was the symptom of my bug too), but to redrawing. Using F2 and motif (Suse80 is still giving me a hard time to run gtk2). Looking at the API doc of setRedraw(boolean) in Control /** * If the argument is <code>false</code>, causes subsequent drawing * operations in the receiver to be ignored. No drawing of any kind * can occur in the receiver until the flag is set to true. * Graphics operations that occurred while the flag was * <code>false</code> are lost. When the flag is set to <code>true</code>, * the entire widget is marked as needing to be redrawn. * <p> * Note: This operation is a hint and may not be supported on some * platforms or for some widgets. * </p> * * @param redraw the new redraw state * * @exception SWTException <ul> * <li>ERROR_WIDGET_DISPOSED - if the receiver has been disposed</li> * <li>ERROR_THREAD_INVALID_ACCESS - if not called from the thread that created the receiver</li> * </ul> * * @see #redraw * @see #update */ Table: public void setRedraw(boolean redraw) { checkWidget(); super.setRedraw(redraw); getHeader().setRedraw(redraw); } SelectableItemWidget public void setRedraw (boolean redraw) { checkWidget(); if (redraw) { if (--drawCount == 0) redraw(); } else { drawCount++; } } Widget: public void setRedraw (boolean redraw) { checkWidget(); } Btw. checkWidget doesn't contain anything meaningful regarding this problem. But see for yourself. protected void checkWidget () { if (!isValidThread ()) error (SWT.ERROR_THREAD_INVALID_ACCESS); if (isDisposed ()) error (SWT.ERROR_WIDGET_DISPOSED); Hope that helps to get you started. Btw. I haven't seen anybody else on the cc: to this bug. Hence I wanna let you know that this bug doesn't bother me at all. I introduced setRedraw() to fix something else and it is of no use anymore to me. To make a long story short -> I just wanted to feed back, but for me it doesn't make any difference if this bug is fixed in June or June 2003 ;-)
oops. Messed it up a bit. I was saying "Widget:" below, but it is "Control:". Sorry. Btw. I don't have a clue about SWT, but regarding the problem below ... redraw is initialized to 0. So when I call setRedraw(true) the first time it won't drawCount, not even the second time (as it will stay below 0). (alternative a) Would it be better to check for <= 0, which would mean to change the other two methods redraw() and redraw(..) too?! (alternative b) From my point of view a solution could be to change the behaviour of setRedraw(boolean) to check that drawCount is not decremented below 0. (see below) But I obviously don't know who else is mainpulation drawCount.. Just my 2 cents. SelectableItemWidget (current Implementation) public void setRedraw (boolean redraw) { checkWidget(); if (redraw) { if (--drawCount == 0) redraw(); } else { drawCount++; } } SelectableItemWidget (alternative) public void setRedraw (boolean redraw) { checkWidget(); if (redraw) { if (drawCount > 0) --drawCount; if (drawCount == 0) redraw(); } else { drawCount++; } } A side note. alternative a) would be as good as alternative b) *if* the special meaning of drawCount == 0 is reflected in the code, like introducing a special method for that, e.g. needsRedraw().
The original problem was against Windows and that problem is fixed. The problem that Mariano described is on Motif and does not occur using the test code provided. Mariano, please feel free to open a new PR describing the problem you are having on Motif. Fixed > 20020809.
