Community
Participate
Working Groups
Build Identifier: 3.4.2.M20090107-0800 If you open the preference page, then from there click on a Browse button to open a file browser dialog, then trigger some event that causes an org.eclipse.jface.dialogs.MessageDialog.openWarning() call to happen, you end up with a warning dialog under the file browser, and neither one can actually be clicked on, thus causing a locking situation. The user must force quit the application. There does not seem to be an appropriate SWT style that will allow a dialog like this to be on top of a File Browser or similar system level dialog (such as the Font picker). Reproducible: Always Steps to Reproduce: 1. Go to a preference page that has a Browse... button on it. Click it to open a file browser dialog 2. With that dialog open, call org.eclipse.jface.dialogs.MessageDialog.openWarning() 3. Two windows are open, neither one can be dismissed. Must force quit the application.
Does this happen in 3.5 or 3.6 carbon? There won't be any updates to the 3.4 stream (that I'm aware of.)
This is being seen in Lotus Sametime and the team has confirmed that they see this issue on 3.5.2 Carbon.
The problem still happens in carbon HEAD. Here is a test case. public static void main(String[] args) { final Display display = new Display(); final Shell shell = new Shell(display); shell.setLayout(new GridLayout()); Button b = new Button(shell, SWT.PUSH); b.setText("Open File Dialog"); b.addListener(SWT.Selection, new Listener() { public void handleEvent(Event event) { FileDialog dialog = new FileDialog(shell, SWT.NONE); display.asyncExec(new Runnable() { public void run() { // Problem does not happen with MessageBox // MessageBox box = new MessageBox(shell, SWT.NONE); // box.setText("Hi"); // box.setMessage("Hello"); // box.open(); final Shell dialog = new Shell(shell, SWT.DIALOG_TRIM | SWT.APPLICATION_MODAL); dialog.setLayout(new GridLayout()); Button b = new Button(dialog, SWT.PUSH); b.setText("Close"); b.addListener(SWT.Selection, new Listener() { public void handleEvent(Event event) { dialog.close(); } }); dialog.pack(); dialog.open(); while (!dialog.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } } }); dialog.open(); } }); shell.pack(); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); }
Comment above is mine.
Created attachment 169855 [details] patch This is a possible fix for HEAD. It needs a lot more testing. Depending how testing goes it will be released after 3.6 ships.
Fix is working for us for file dialog. Sametime team is now requesting similar fix for directory dialog.
Do you want Tim to open a separate bugzilla for DirectoryDialog?
No need. Note that I will only be able to investigate the DirectoryDialog case next week.
Created attachment 173823 [details] patch for HEAD (FileDialog and DirectoryDialog)
Fixed > 20100708 (HEAD only)
Can you please include this fix in 3.6.1?
Felipe, please review for 3.6.1
Fix released to R3_6_maintenance.
