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.
Sometimes - but not always - after starting a new Jackpot session, the progress dialog does not disappear after it is finished. It is nonmodal so I can continue work, but I need to push the dead dialog offscreen to get it out of the way.
051111, b60, org.netbeans.jackpot [1.1.7 051112] org.netbeans.modules.jackpot/1 [1.1.7 051112 @BUILD_NUMBER_SUBST@] org.netbeans.modules.jackpot.rules [1.1.4 051112]
BTW - close button on the dialogs does nothing. Have to restart IDE to clean up.
Added dispose() method to BuildMonitor interface, builder uses a try/finally block to ensure it gets called regardless of any build exceptions.
I'm not sure this is fixed as I think I saw it again using an updated NBM: org.netbeans.modules.jackpot/1 [1.1.11 051122]
Found a system that reproduced this problem. It turns out that on some systems Dialog.setVisible(false) is not sufficient to get rid of a dialog -- you have to explicitly call Dialog.dispose(), which the jackpot module now does.
Just failed for me again, using latest Mustang on Linux and org.netbeans.modules.jackpot/1 [1.1.17 060113] Note Jan 17, 2006 3:05:38 PM org.netbeans.modules.jackpot.BuildMonitor buildStarted INFO: begin compile Jan 17, 2006 3:05:39 PM org.netbeans.modules.jackpot.BuildMonitor setTotalSourceFiles INFO: Parsing 1,403 source files Jan 17, 2006 3:06:23 PM org.netbeans.modules.jackpot.BuildMonitor buildFinished INFO: total compile time=25.828 seconds Jan 17, 2006 3:06:23 PM org.netbeans.modules.jackpot.BuildMonitor buildFinished INFO: 61 errors, 0 warnings and OK-looking output in Jackpot Log.
BTW from a UI perspective I would anyway recommend getting rid of the dialog and just using ProgressHandle. Or at least add a Cancel button to the dialog.
*Might* have been a symptom of an out-of-memory condition, but I did not see any dialog about it if so.
Tom, could you please try to add: try { Thread.sleep(50); } catch (InterruptedException e) {} right before Dialog.setVisibility(false); (into the AWT Event Thread)? It might help.
I think I should add some explanation: there is a JDK bug which causes behaviour very similar to the described behaviour. The Thread.sleep(50) is a workaround to it. Please see issue #54585 for more information.
I switched the progress dialog to the IDE's progress status widget (which Jesse preferred anyway). So because I am no longer opening a progress dialog anymore, I think it's safe to really close it again. BTW, the try/finally logic for clearing the dialog is still there.