Bugzilla – Full Text Bug Listing
| Summary: | [Dialogs] activating the system menu of PopupDialog closes the popup | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Tom Hofmann <eclipse> |
| Component: | UI | Assignee: | Eric Williams <ericwill> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | minor | ||
| Priority: | P5 | CC: | apa3a, carsten.pfeiffer, ericwill, gheorghe, snorthov |
| Version: | 3.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux-GTK | ||
| Whiteboard: | |||
|
Description
Tom Hofmann
In our dialog, we hook SWT.Deactivate and close our dialog when our shell deactivates....UNLESS we are deactivating because one of our children is activating. Ideally, there would be an SWT expression we could use during our dialog shell's SWT.Deactivate event to determine that we are deactivating because our system menu (or any other menu associated with our shell) is opening. I can't see that there's a way to tell that this is the situation. The display's active shell is still our shell during this event, and we don't know who *is* getting activated (which would be helpful). Would there be any other way via SWT to tell that our shell's deactivate event is occurring because our own menu is opening? If there were a way to tell this, we could fix this bug and also eliminate a hack fix for bug #115785. CC'ing Steve for ideas. *** Bug 161939 has been marked as a duplicate of this bug. *** pinging again for SWT guidance on this issue? We are having similar problems in bug #198925. Is it hopeless for us to try to make decisions during Deactivate based on who is getting activated? Not really. I believe the new versions of GTK don't deactivate when a menu is popped up. When you say "popup's system window menu", do you really mean the operating system menu (ie. On Windows, 'Move' 'Size' 'Minimize' etc)? no, I don't really mean the system menu. It's a menu we create that serves a similar purpose. Here's the snippet we use to create it: Menu menu = menuManager.createContextMenu(getShell()); Rectangle bounds = toolBar.getBounds(); Point topLeft = new Point(bounds.x, bounds.y + bounds.height); topLeft = getShell().toDisplay(topLeft); menu.setLocation(topLeft.x, topLeft.y); menu.setVisible(true); In this bug, the problem was that our shell got deactivated when the menu becomes visible, and since we have some groovy "close when deactivated" code, we would close. The desire was to only close when we are deactivated due to "shells we don't know about" getting activated. The real question is...is there a way that we can know during deactivation who is getting activated so that we can decide whether we want to close or not? We have all kinds of hacks right now to work around this basic problem. Not really. Do you also want to "close when deactivated" when the user clicks on another application? How about closing the previous when a new one is activated. Does your code fail in the Mac too? ie. listening for activate instead The workaround getShell().getShells().length == 0 unfortunately breaks Popup Dialogs that actually do have sub shells. E.g. one with a CCombo inside that opens another popup. In that case clicking outside of the popup will not close it anymore. My workaround (in a subclass of PopupDialog) is adding another ACTIVATED listener on the *parent* shell and closing the popup when the parent shell is activated. Maybe not perfect, but better than the current implementation. Oh and btw, the getShell().getShells().length == 0 workaround causes the mentioned side effect on all platforms, not just Linux. This has been resolved with the fix for bug 466500. *** This bug has been marked as a duplicate of bug 466500 *** |