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.
A dialog opened from Advanced mode dialog is not displayed when the help window is simultaneously opened. It is high priority because it blocks commit validation suite. To reproduce: - open help window (Help|Help Contents) - call checkout command from main menu (Versioning|CVS|Global CVS Checkout) - dialog "Enabling Advanced CVS Command Options" appears - click "Global CVS Check Out..." button => it seems requested dialog is shown for a second but it doesn't stay open and only the help window remains Build 20040812-0503, JDK1.5.0-b59, WindowsXP.
The behavior is non-deterministic. The first time the behavior was as described above. And the Help window was at the right side of the modal dialogs. After several more attempts the Help window started to be displayed on the left side (even though I've moved it to the right several times) and both checkout dialog and Help was displayed next to each other correctly. After several more attempts Help window was closed after checkout dialog was displayed. I do not see a way how this can be fixed in VCS or what is wrong with the mechanism of how the dialogs are displayed.
The dialog is shown, but it ends up behind the main window - at least, that's what happens on my mac. Martin, where is the code that shows this dialog?
On my windows the dialog is not shown anyway. The "Enabling Advanced CVS Command Options" dialog is probably here: /cvs/vcscore/src/org/netbeans/modules/vcscore/actions/CommandMenu.java
Yes. It's method showFirstTimerDialog() in CommandMenu. The second, Checkout dialog is opened in org.netbeans.modules.vcscore.commands.CommandProcessor, line 486.
Note also that clicking cancel on the dialog when the help window is open causes the dialog to be closed and then re-opened. What is happening, at least on my mac is that, when the first dialog is closed, the help window reparents back into a JFrame; before that JFrame has a chance to be shown, the second dialog is shown; so javahelp creates another dialog to show help in before the frame has actually shown up. This in turn screws up the toolkit royally. The CVS Checkout dialog is created, but behind the main window. When I front it using the keyboard and give it focus, it is semi- unresponsive. Clicking the down arrow on the combo box causes an IllegalStateException, because *the combo box, and everything else in the CVS Checkout dialog is returning false from isShowing()* - the whole dialog thinks it's not onscreen. Probably the different behavior on other platforms is some variant on some kind of race condition in the Toolkit implementation - disposing frames that have just had show() called on them, before they have really appeard, while at the same time a dialog has just had show() on it called seems to have disasterous consequences. Other than deleting all of the craziness that makes the help window stay enabled when there are modal dialogs, or setting up some client property for the first dialog to make help ignore it, I'm not sure this *can* be fixed.
Okay, I've put a workaround in place. It ain't pretty. Before the "First Timer" menu is shown, it vcscore now sets the system property "javahelp.ignore.modality" to true; DialogDisplayerImpl in turns reads this property, sets it to false, and if it was true, sets a client property on the root pane of the dialog; JavaHelp then reads the client property when deciding if it should react to the dialog. Like I said, not pretty. Checking in vcscore/src/org/netbeans/modules/vcscore/actions/CommandMenu.java; /cvs/vcscore/src/org/netbeans/modules/vcscore/actions/CommandMenu.java,v <-- CommandMenu.java new revision: 1.16; previous revision: 1.15 done Processing log script arguments... More commits to come... Checking in core/windows/src/org/netbeans/core/windows/services/ DialogDisplayerImpl.java; /cvs/core/windows/src/org/netbeans/core/windows/services/DialogDisplayerImpl.java,v <-- DialogDisplayerImpl.java new revision: 1.6; previous revision: 1.5 done Processing log script arguments... More commits to come... Checking in core/javahelp/src/org/netbeans/modules/javahelp/JavaHelp.java; /cvs/core/javahelp/src/org/netbeans/modules/javahelp/JavaHelp.java,v <-- JavaHelp.java new revision: 1.26; previous revision: 1.25 done Processing log script arguments... Mailing the commit message to cvs@core.netbeans.org, cvs@vcscore.netbeans.org (from tboudreau@netbeans.org)
Tim you *must* document such system properties in an arch desc. This a backdoor API.
Where?
Both for core/windows and core/javahelp, since both interpret the property - once as a sys prop, once as a JComp client prop. Two backdoor APIs, really.
Documented in javahelp arch docs; there are no winsys arch docs. cvs commit: Examining . Checking in arch-core-javahelp.xml; /cvs/core/arch/arch-core-javahelp.xml,v <-- arch-core-javahelp.xml new revision: 1.13; previous revision: 1.12 done
openide/arch/arch-openide-windowsystem.xml
Verified in build 20040813-0100