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.

Bug 168260 - API to fire activated nodes/selection context change on modal dialog show
Summary: API to fire activated nodes/selection context change on modal dialog show
Status: REOPENED
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: issues@platform
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-08 04:36 UTC by _ tboudreau
Modified: 2011-02-24 14:19 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description _ tboudreau 2009-07-08 04:36:01 UTC
This could prevent at least one deadlock - see issue 168109 and the attached thread dump
http://www.netbeans.org/nonav/issues/showattachment.cgi/84438/threaddump-fixed.txt

If DialogDisplayer.getDefault() is showing a modal dialog, there is no reason to update the current activated nodes or
selection context until that dialog is closed.  This would probably improve performance of showing dialogs a bit, and it
is certainly unnecessary work since the user has no access to main-menu or toolbar actions while a modal dialog is open.

Could be solved either by delaying any selection context changes until a modal dialog is closed, or by firing a change
to Lookup.EMPTY for selection context and Node[0] when a modal dialog is shown - either one would prevent Actions from
trying to do expensive work (in the thread dump above, look up the owning project of some files on the clipboard) when
the actions cannot possibly be really used.
Comment 1 Stanislav Aubrecht 2011-02-24 10:51:00 UTC
the scenario in bug #168109 seems valid to me - the refactoring dialog makes some changes so the activated nodes should change to reflect those changes in the IDE...
Comment 2 _ tboudreau 2011-02-24 14:19:58 UTC
Changing to enhancement then.  It is still unnecessary overhead for most dialogs;  ideally no change would be the default for most dialogs, and let the dialog displayer provide some hint for the case that the dialog actually needs this behavior.