Community
Participate
Working Groups
AW (21.03.00 18:58:21) SWT 0.39: If I open a Shell which is already open it is brought to front under Windows but not on Motif. What is the intended behavior? Should I always use a Shell.moveAbove(null) after calling Shell.open()? SN (3/21/00 5:49:05 PM) This is a bug. The intent of shell.open () is that it be only called once but when called multiple times, it should bring the shell to the front like Windows (I guess ... ?). You shouldn't really be calling it multiple times but it's not harmful. To change the Z-order, you should be using the Z-order calls (moveAbove etc.). NOTES: McQ (27/11/2000 2:11:02 PM) - Clarification: It is a bug in application code to call Shell.open() more than once. Applications should not rely on this behavior. We should probably make open throw an SWTException if it is called, but this is low priority. Moving to inactive.
Inactive.
Moving from Later.
Investigating, for consistency work. Ran the following snippet on XP, GTK, Motif(Linux), and Mac. Here are the results: XP - Shell 1 brought to front on 2nd open GTK - Shell 2 stays in front Motif - Shell 2 stays in front Mac - Shell 1 brought to front on 2nd open Will consult with SN on what we think the "correct" behavior is. import org.eclipse.swt.widgets.*; public class Main { public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); shell.setText("Shell 1"); shell.open(); Shell shell2 = new Shell(display); shell2.setText("Shell 2"); shell2.open(); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }
The spec is pretty clear on this one for once. I had a go at fixing this recently on GTK and Motif but ran into trouble (a subtle case that I can't remember right now). Feel free to try again. I could have been on crack.
I think you need to run an event loop before X knows which shell is on top.
The spec for Shell.open says that it: * Moves the receiver to the top of the drawing order * marks it visible * sets the focus * asks the window manager to make the shell active So we will try to make sure it does all of those things on all platforms, even on the 2nd invokation. In addition, it probably makes sense to de-iconify it if it happens to be iconified...? Steve? The above snippet needs more code. Here it is again: import org.eclipse.swt.widgets.*; public class Main { public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); shell.setText("Shell 1"); shell.open(); Shell shell2 = new Shell(display); shell2.setText("Shell 2"); shell2.open(); shell.setMinimized(true); shell.setVisible(false); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }
Steve, what do you think about a plain-and-simple "set a flag" solution that would be basically the same code in Shell on all platforms...? For example, 1) Add a field: boolean openCalled = false; 2) Check and set the flag after the checkWidget() in the open() method: if (openCalled) { reopen (); return; } openCalled = true; 3) ... where "reopen()" simply does the following (all API calls): void reopen () { if (isDisposed ()) return; if (!getVisible ()) setVisible (true); if (getMinimized ()) setMinimized (false); bringToTop (); // or moveAbove (null); setActive (); setFocus (); } It's kind of "brute force" but the advantages are: - no subtle cases - no event loops on X - it's already implemented, and it works <g> Disadvantages: - extra field (but Shells are only order n) - extra method (but it's small) - widget makes a bunch of api calls (but very few people will run this code)
You need to determine why the current code doesn't work before adding bogus flags to remember state.
It's not clear to me that open should do a setFocus(). It should just restore focus to the control that had it previously in that shell.
Still a problem on GTK using 3.1 M7. I've changed the Workbench uses (in the two Workbench.setPerspective methods) to use a new internal method, WorkbenchWindow.makeVisible(), which uses shell.setMinimized(false) and shell.setActive().
Shell.open() does attempt to restore the previous focus. CAR's code sample is wrong.
I'm looking at this again.
Fixed > 20050525
Now it's fixed.
In bug 96700, Doug says Shell.open() still does not have the desired effect of bringing the window to top.
Does the test code in this bug report fail for him?
The code above does not test the scenario where the window needs to be brought to front, either due to another SWT window being frontmost, or another app. Doug, can you clarify which scenario is still a problem on GTK?
See Bug 96700 comment #6.
