Description Knut Radloff 2001-10-11 14:19:50 EDT

Run the code below.
The call to canvas.setRedraw(true) makes the canvas visible on Windows.
This works on Motif.

import com.ibm.swt.*;
import com.ibm.swt.widgets.*;

public class PR_1G975VG {

public static void main(String[] args) {
	final Shell shell = new Shell();
	Canvas canvas = new Canvas(shell, SWT.NULL);

	canvas.setSize(100, 30);
	canvas.addListener(SWT.Paint, new Listener() {
		public void handleEvent(Event e) {
			e.gc.setBackground(shell.getForeground());
			e.gc.fillRectangle(e.getBounds());
		}
	});
	canvas.setVisible(false);
	canvas.setRedraw(false);
	System.out.println(":1: " + canvas.getVisible());
	canvas.setRedraw(true);
	System.out.println(":2: " + canvas.getVisible());
	
	shell.open();
	Display display = shell.getDisplay ();
	while (!shell.isDisposed ()) {
		if (!display.readAndDispatch ()) display.sleep ();
	}
}
}
NOTES:

SN (2/15/01 12:39:56 PM)
	Not quite sure how to fix this.  On Windows, WM_SETREDRAW sets the WS_VISIBLE bits
	for the HWND without actually hiding the window and issueing the paints necessary to
	redraw the area where the widget used to be.  This is internal Windows magic because
	anyone else cannot touch WS_VISIBLE without causing a redraw.   The WS_VISIBLE bits
	are also used by ShowWindow () to show and hide the window.  The problem is that the
	same bits are used by both calls.

	I am tempted to say "platform behavior" but I can see the problems that this causes.

KR (2/28/01 12:03:07 PM)
	I came across this problem when I started using the emulated Motif Table with the Windows 
	Leapfrog. All the table viewers now have a header without the table knowing about it (nobody 
	ever made it visible). This messes up the table rendering and navigation.
	I think this has to be fixed.
	If setRedraw is called with true and the window is invisible couldn't you cache the value 
	and set it when setVisible(true) is called?

SN (2/28/01 12:53:42 PM)
	I can cache values but I hate to do this because this will lead to sync bugs.  Also, Windows
	really does make the window visible using WS_VISIBLE so making it not visible might cause
	flashing.  I'd have to experiment.  The other thought I had was to ignore calls to setRedraw
	when the widget is not visible but this would mean that calls to setVisible that were issued
	between setRedraw (false)/setRedraw (true) would have to be ignored as well.

	I want to help but I'm not sure how.

SN (3/22/01 12:17:32 PM)
	More information.  It seems that certain widgets have the bug and others don't.
	For example, the List widget does not become visible for setRedraw false/true.
	Still thinking about a solution.