Bugzilla – Full Text Bug Listing
| Summary: | [Dialogs] find dialog hides main window | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Thorsten van Ellen <thorsten.van.ellen> | ||||||
| Component: | SWT | Assignee: | Steve Northover <snorthov> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | bhuvanmehta, carolynmacleod4, Dave_Thomson, fwp, markus.kell.r | ||||||
| Version: | 2.1.1 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows 2000 | ||||||||
| Whiteboard: | stalebug | ||||||||
| Attachments: |
|
||||||||
|
Description
Thorsten van Ellen
This is a standard non - modal dialog. Moving to SWT for comment. Can't seem to make this happen outside of Eclipse. Carolyn, can you try? I have definitely seen an example because I went looking for one when I noticed the behavior in eclipse. Of course, I can't find an example at the moment (Murphy's Law). There are plenty of examples of the opposite behavior in the OS - you bring up a dialog, switch to another app, then switch back - and where is the dialog? You need to minimize stuff to find it. For an example of that behavior, open a File Explorer, select any file, bring up its context menu and select Properties. Bring another application to the front, then bring File Explorer to the front again - the dialog is not on top any more. I will keep looking for the behavior described here - it probably depends on the dialog style, and I just have to find the right non-modal dialog somewhere. In the meantime, you don't actually have to minimize everything to find the eclipse window - you can just minimize and restore the eclipse window from the task bar. An easy way to do this (on XP - not sure if this works on 2K also) is to click on eclipse in the task bar (to bring it to the front), then click on it again (to minimize it), then click it again (to maximize). So basically, it takes 2 extra clicks to get where you want. Sorry all I can offer at this time is a slightly faster work-around and not a concrete example, but I know I've seen one. My problem is that in order to debug this, I need a stand alone SWT example and can't seem to create one. CAR to find me a snippet! Interesting. I had a little standalone modeless dialog test lying around, and
I just ran it. I'll paste the code below, but it does NOT have the same
problem as eclipse.
When I "sniff" the class, window style, and extended style bits, I get the
exact same thing for both dialogs (my little modeless guy and the eclipse Find
dialog), so it doesn't appear to have been created any differently:
class="#32770" style=0x96C80000 ex=0x100101
Also, the "sniffed" parent is the same for both (Desktop).
Here's the code. Not too useful, though, as it doesn't show the problem.
import org.eclipse.swt.*;
import org.eclipse.swt.widgets.*;
import org.eclipse.swt.layout.*;
import org.eclipse.swt.events.*;
public class DialogTest {
static Display display;
static Shell shell;
static Text text;
public static void main(String[] args) {
display = new Display();
shell = new Shell(display);
shell.setLayout(new GridLayout());
shell.setText("Modeless Dialog Test");
Button button = new Button(shell, SWT.PUSH);
button.setText("Open Modeless Dialog");
button.addSelectionListener(new SelectionAdapter() {
public void widgetSelected(SelectionEvent e) {
final Shell dialog = new Shell(shell,
SWT.DIALOG_TRIM | SWT.MODELESS);
dialog.setLayout(new GridLayout());
dialog.setText("Modeless");
final Text textField = new Text(dialog,
SWT.SINGLE | SWT.BORDER);
textField.setLayoutData(new GridData
(GridData.FILL_HORIZONTAL));
Button append = new Button(dialog, SWT.PUSH);
append.setText("Append");
append.setLayoutData(new GridData
(GridData.FILL_HORIZONTAL));
append.addSelectionListener(new
SelectionAdapter() {
public void widgetSelected
(SelectionEvent e) {
String result =
textField.getText();
text.append(result);
}
});
Button close = new Button(dialog, SWT.PUSH);
close.setText("Close");
close.setLayoutData(new GridData
(GridData.FILL_HORIZONTAL));
close.addSelectionListener(new SelectionAdapter
() {
public void widgetSelected
(SelectionEvent e) {
dialog.close();
}
});
dialog.pack();
dialog.open();
};
});
text = new Text(shell, SWT.MULTI | SWT.H_SCROLL |
SWT.V_SCROLL);
GridData data = new GridData(GridData.GRAB_VERTICAL |
GridData.FILL_HORIZONTAL);
data.heightHint = 100;
text.setLayoutData(data);
shell.pack();
shell.open();
while (!shell.isDisposed()) {
if (!display.readAndDispatch()) display.sleep();
}
}
}
HAck Shell (Decorations?) to never send SWT.Activate or SWT.Deactivate. This will destroy Eclipse but see if it fixes the problem. Hack to get rid of ON_TOP style. Does this fix the problem? Getting rid of ON_TOP appears to fix the problem. The comment says that the ON_TOP style (WS_EX_TOPMOST) was problematic on Win 98 and NT when there are multiple dialog children of a window... but the behavior we are seeing does not match the comment (it says the dialog will be behind the parent). Perhaps this is some related problem in the current versions of Windows (2K, XP, ...). We may be able to work around having this bit set on all Windows platforms. By the way, the modeless Find dialog in Notepad sniffs as follows: class="#32770" style=0x94C820C4 ex=0x10501 Car, should we investigate setting/clearing SWT.ON_TOP in WM_SHOWWINDOW? Hi Steve! What do you mean with "make this happen outside of Eclipse"? Why do you want to do that? Does that help you? Some thoughts: I assume, if the dialog has been modal, the OS or eclipse would already support correct handling, but with non-modal dialog, it does not. I would expect that each such non-modal-dialog (not every non-modal dialog) has to hold a reference to the main window and at "activation" it has to bring up: 1. the main window 2. the non-modal dialog in front of the main-window. Perhaps it makes sense to give such dialogs a special name: semi-modal: semi because such dialogs are not totally independend from another, but the user can focus several windows. Perhaps it makes sense to create a special class for this, that has a reference to a "main" window. best regards Thorsten van Ellen > "make this happen outside of Eclipse"?
This means "create a stand alone example, like those found on the SWT snippets
page that demonstrates the problem". This sort of thing allows us to isolate
the exact circumstances.
It seems from our analysis that Windows has a bug involving WS_EX_TOPMOST but
we don't have the exact case. This was proved when we commented out the code
that set this style (causing the Eclipse problem to go away). Carolyn was
looking into this.
*** This bug has been marked as a duplicate of 18399 *** Oops, got the duplicate thing the wrong way round. *** Bug 18399 has been marked as a duplicate of this bug. *** Aha! Found an example of this with an MS Word Find dialog on my home machine (Windows XP, Word 2002, Notes 6). Open 2 copies of Word on two different Word files. Open Lotus Notes. In one of the Word files, Edit -> Find... Then use Alt+Tab to go to Notes. Type something into an email and then use Alt+Tab to go back to Word. I only got the dialog - the Word window did not take focus. They must be hitting the same bug in WS_EX_TOPMOST that we are. This bug is still an annoyance in Eclipse 3.1M6 on WinXP SP2. Looks like MS has not fixed their bug in WS_EX_TOPMOST yet :-(. However, I managed to create a snippet to reproduce this outside of Eclipse. Created attachment 19713 [details]
Snippet to reproduce in pure SWT
To reproduce:
- have your development Eclipse in maximized mode
- run the snippet
- press the button
- Alt-Tab (you're back in Eclipse now)
- Alt-Tab
=> only the "Modeless" dialog shows up
It looks like the problem comes from an additional child shell of the main
shell (see comment in the snippet). In Eclipse, the Task View's
ComboBoxCellEditor creates such a shell .
*** Bug 84873 has been marked as a duplicate of this bug. *** Even though bug 18399 (which has been marked as a duplicate of this bug) already mentions this, I would like to point out that this problem is not limited to modeless dialogs (see also attachment #17815 [details]). In the snippet provided in comment #17, SWT.MODELESS can be changed to SWT.APPLICATION_MODAL, and the bug will still show up. Created attachment 265208 [details]
Shell-Focus-Issue
Hello, Do we have any update here wrt fixing the problem with shell focus when switching to other application with ALT+TAB. Problem can also be seen and reproduced with JavaDoc control. (Refer to attachment) Any workarounds to creating shell which BLOCKS the shell to get focus outside eclipse workbech? -- Thanks and Regards, Bhuvan Mehta This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |