[news.eclipse.platform.swt] Re: Halting SWT thread but repainting

[Gordon Hirsch <eclipse@xxxxxxxxxxx>]

Hans wrote:
> Just for the archive - here is the solution: use Shell.setEnabled(false) 
> to block it while the Swing process is running.  This will reject any 
> use input but still handle repaint events.

Hans,

Wouldn't the setEnabled(false) call visually change the SWT window (i.e. 
grey it out)? The javadoc seems to say so.

Also, if I may respond late to a previous post of yours on this 
thread... The strategy of opening a hidden SWT modal dialog in 
conjunction with the Swing dialog, while messy, can be made to work. The 
trick is to add a focus handler to the hidden SWT dialog; whenever it 
gains focus, you can transfer control right back to the Swing dialog.

My main concern is that some unusual event will cause this hidden modal 
dialog to remain open after the Swing dialog closes. That would 
permanently disable all input to my application. Not good. So, I'd 
really like to find a cleaner way...

> So a pattern such as the following can be employed (from SWT thread, 
> assuming there is a boolean field "busy" in the class):
>
>
>       SwingUtilities.invokeLater(new Runnable() {
>            public void run() {
>                try {
>                             // Do the Swing work, e.g. modal dialog
>                }
>                 finally {
>                         busy = false;
>                 }
>             }
>         });
>                
>     shell.setEnabled(false);
>     Display display = shell.getDisplay();
>     while (!shell.isDisposed() && busy) {
>         if (!display.readAndDispatch()) {
>             display.sleep();
>         }
>     }
>     shell.setEnabled(true);
>
>
> Hans