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.
Using the graphical Swing editor; editing a MenuItem's Action causes the loss of the item's associated shortcut key. 1. I have some JMenuItem which already has an Action assigned and a shortcut key assigned. 2. Edit the Action -- using the Properties sheet or using the popup Action Editor makes no difference. 3. The previously-assigned shortcut definition gets cleared from the MenuItem.
Created attachment 78375 [details] Before editing an item's Action
Created attachment 78376 [details] After editing the item's Action
You should either use the shortcut (accelerator), or the action. The menu items are not designed to use both. The problem is (I suspect) that setting the action resets the shortcut (the menu item then takes the action's one). Can't you have the shortcut defined in the action?
Yes, after some exploration I see that you are correct. I can (with some hacking around - some of the Actions are instantiated in library code) define the accelerator in the Actions and this is certainly better. However, I would, in this case, expect/like the form-editor to reflect the shortcut as defined in the Action instead of merely displaying nothing (which seems to hint that no shortcut is set.) Perhaps reclassify this as an RFE instead of a bug? ;-)
Form editor should display the shortcut in the propeties if it was set through action - that's reasonable request. However if the action has no shortcut, then it rewrites whatever shortcut was set before. Form editor can hardly do anything about that. If you want the shortcut anyway, you must set it *after* setting the action (i.e. the properties are order-dependent). Unfortunately, I don't see a good way how to handle the dependent properties automatically - the preferred behavior is different case by case. The solution that form editor would ask whether you want to rewrite a property by setting another property or keep the previously set value is IMO too heavyweight.
Well, I guess there is no need to have this issue as INCOMPLETE defect report :) According to the comments below, I am changing this to RFE.