This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | modal dialog can unexpectedly bring down subsequent dialog | ||
---|---|---|---|
Product: | platform | Reporter: | ivan <ivan> |
Component: | Dialogs&Wizards | Assignee: | Jiri Rechtacek <jrechtacek> |
Status: | RESOLVED WONTFIX | ||
Severity: | blocker | CC: | mentlicher |
Priority: | P3 | Keywords: | API |
Version: | 6.x | ||
Hardware: | Sun | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
ivan
2008-05-08 00:25:22 UTC
DialogDesciptor has a way how to solve this problem, if I understand the problem correctly. DialogDescriptor has a field 'leaf' (http://bits.netbeans.org/dev/javadoc/org-openide-dialogs/org/openide/DialogDescriptor.html#setLeaf(boolean)) which was designed to help in such cases: The application has the main window W, once new dialog D1 is opened then W will be parent of D1. And then if a next dialog D2 is opened, D1 is parent of D2. i.e. W<-D1<-D2. When an user closes D1, D2 is closed as well because its parent disappears. That's the case why 'leaf' field is there. Construct D1 with leaf=true in its constructor or use DD.setLeaf(true) and D1 cannot become as parent of other dialog, e.g. W<-D1 and W<-D2. In the end, both dialog can close independent each other. Hope it helps, -jiri So you're saying debuggercores attach dialog should mark itself as a leaf? But a dialog may not be able to know if it's a leaf or not. For example, the debuggercore Attach and NewBreakpoint dialogs host panels provided by various debugger implementations. These panels may have actions which pop up more dialogs. I do understand that but the proposed pattern with setLeaf(true) has been applied to such conflicting dialogs up to now. I guess it cannot cover all cases perfectly, it's one of possible workarounds. Perhaps, a ideal solution would be new DD method like setAsTopDialog() which you could apply on your dialog to avoid unintentional closing of it. If you agree I'm going to change this issue to RFE of DialogDescriptor API for that method. Btw. the reason for DD.setLeaf(boolean) method was issue 53525 which came with this problem the first time. IZ 53525 is the exact same problem I've described here. Leafness is not a property one should have to assign. It's a derivative propery and should mean "do I have any children". (I know with Nodes it's a bit more complicated but I don't think dialogs do what Nodes do) When swing/AWT dialogs are created they get assigned an owner. Why is it that that relationship not being used to determine leafness? For that matter, shouldn't a correct swing-level owner relationship bring down D2 when D1 goes away? Wy does NB need to do something extra? It sees to me that the NB dialog code establishes an incorrect parent-child relationship between unrelated dialogs. Instead of "not doing that" isLeaf is a workaround that says ignore that incorrect automatically generated parent-child relationship. Need to new constructor/method in DialogDescriptor API to allow to specify owner of dialog. Not in current plan to fix it NetBeans.org Migration: changing resolution from LATER to WONTFIX |