Community
Participate
Working Groups
When you setRedraw(false) on a widget and then resize the widget and then setRedraw(true), the area that is re-painted after the setRedraw(true) is just the area of the new size of the widget. This is OK if the widget was made larger but this causes cheese if the widget has been made smaller or moved. See the example below to demonstrate this. Note: Fixing this problem may not entirely solve the above problem. public static void main (String [] args) { Display display = new Display (); Shell shell = new Shell (display); final Color red = display.getSystemColor(SWT.COLOR_RED); final Color blue = display.getSystemColor(SWT.COLOR_BLUE); final Canvas canvas = new Canvas(shell, SWT.NONE); canvas .setBounds(10, 70, 100, 100); canvas.setBackground(red); Button b = new Button(shell, SWT.PUSH); b.setText("change"); b.setBounds(10, 10, 100, 40); b.addListener(SWT.Selection, new Listener() { public void handleEvent(Event e) { canvas.setRedraw(false); Point size = canvas.getSize(); if (size.x == 100) { canvas.setSize(300, 300); canvas.setBackground(blue); } else { canvas.setSize(100, 100); canvas.setBackground(red); } canvas.setRedraw(true); } }); shell.open (); while (!shell.isDisposed ()) { if (!display.readAndDispatch ()) display.sleep (); } display.dispose (); } NOTES: VI (27/08/2001 3:53:10 PM) setRedraw should damage call RedrawWindow on the parent and should damage both the old client rect and the new client rect. SN (8/29/01 11:08:06 AM) That sounds like a scary fix.
PRODUCT VERSION: 1.0 132
Document that you should never resize during setRedraw(false).
*** Bug 15014 has been marked as a duplicate of this bug. ***
*** Bug 12356 has been marked as a duplicate of this bug. ***
Veronika, this was the problem that I was asking you about to see whether this was the cheese Randy was seeing.
Steve, we haven't seen any recent problems in draw2d/GEF because of this issue. This affected us back when we first added CellEditors to GEF. We resize the cell editor as you type. Our workaround was to use the technique in one of your snippets to grow the Text control before the OS inserts the new characters. Sorry for the confusion, just wanted to get CC'ed to this.
What is the plan for this bug? It seems like this behavior is a Windows specific bug/feature and that Veronika's workaround could fix the problem. McQ suggested that it just be doc'd to say that you shouldn't resize the widget while setRedraw(false), but it doesn't look like the doc has been updated. It seems reasonable to resize a widget after a setResize(false) for the same reason you would use setRedraw(false) to hide repaints while modifing the child widgets. You could argue that you should call parent.setRedraw(false) before sizing the widget, but that doesn't work when you are resizing a toplevel window.
We could have another go at this. We were afraid to make the changes at the time because they were too scary. Are you seeing this now?
I've checked this out on GTK and it is not a problem there (at least not with the top-level shell resizing). I'm mostly interesting in hearing that this is only a Windows bug and that the setRedraw() method will NOT be updated to include the statement suggested in comment 2. Since I'm planning on trying to fixing this for the eSWT code base I don't mind also submitting a patch if I can figure it out.
It's Windows only. We were hoping to make Veronika's hack fix good someday but there were a bunch of issues with it that I no longer remember.
A fix for this problem is necessary as part of the fix for bug 99266.
talked with SN and I agree with fixing this for RC3
Fixed > 20050614
