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.
Build: NetBeans IDE Dev (Build 090914) VM: Java HotSpot(TM) Client VM, 14.1-b02, Java(TM) Platform, Standard Edition for Business, 1.6.0_15-b03 OS: Linux, 2.6.24-23-generic, i386 User Comments: jiriprox: UOE thrown when assignig shortcut to o.n.m.refactoring.spi.impl.RefactoringContextAction and invoking it in editor or project view. Stacktrace: java.lang.UnsupportedOperationException: Not supported. at org.netbeans.modules.refactoring.spi.impl.RefactoringContextAction.actionPerformed(RefactoringContextAction.java:77) at org.openide.windows.TopComponent.processKeyBinding(TopComponent.java:1052) at javax.swing.JComponent.processKeyBindings(JComponent.java:2897) at javax.swing.JComponent.processKeyEvent(JComponent.java:2814) at java.awt.Component.processEvent(Component.java:6040) at java.awt.Container.processEvent(Container.java:2041)
Created attachment 87664 [details] stacktrace
After this change http://hg.netbeans.org/jet-main/rev/e9b4368f075c it should no longer be possible to assign a shortcut to that action.
*** Issue 172246 has been marked as a duplicate of this issue. ***
Fix uses misplaced.action.allowed to circumvent ValidateLayerConsistencyTest. The root problem is that there is no distinction made between true invocable Action's and placeholders (in this case a Presenter.Menu). The better fix in this case would perhaps be to not implement Action at all, only Presenter.Menu, and ensure that keyboard customizers only permit bindings of Action's (if that is not already the case). In other cases this is problematic because ContextAwareAction extends Action, which is incorrect since the action might be meaningless with no context; removing the extends clause would be incompatible but perhaps we could make a ContextAwareAction2 with no superinterface (since only a limited number of bits of infrastructure ever need to check instanceof ContextAwareAction and these could be easily updated).
Jesse, are you mixing unrelated things into one issue? ContextAwareAction was always supposed to extend Action and there is no reason why it shall not. If action without context is not usable, it shall be disabled or have different workflow - show a dialog, etc. Every action can either be disabled or do something, so the design is ok. In the case of RefactoringContextAction.actionPerformed one could show a dialog and allow user to choose from the available refactorings. The rest of the workflow would stay the same.
"if action without context is not usable, it shall be disabled or have different workflow" - yes this is a possible alternative to throwing UOE or an assertion error or beeping or simply doing nothing, but there is no user _value_ in this new UI code - you are just working around our design mistake in forcing placeholders to also implement the full Action interface. There are indeed some cases where a zero-context action variant is wanted, but more cases where this makes no sense for the UI. It would be preferable to just not be an ActionListener to begin with, or otherwise for there to be no option in the GUI to bind this placeholder to a keystroke. A more compatible fix might be something like public RefactoringContextAction(/* no context arg */) { this(null); putValue("placeholder", true); } public void actionPerformed(ActionEvent ev) { assert context != null; // continue... } where ValidateLayerConsistencyTest and the keybinding dialog would both know to ignore Action's for which Boolean.TRUE.equals(a.getValue("placeholder")).
Re: "no user value" - it guess the accessibility can be slightly improved this way. The implementation is not complicated. In fact the action can only show a popup menu with the menu items visible elsewhere. If there ever is support for declarative actions with Presenter.Menu showing some set of subactions, it shall provide this kind of fallback. Much simpler than redesigning (misused, imho) API.