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.
macosx, jdk 1.4.2, nb 4.1rc I've tried to manually add a new autoupdate center. 1. no such action on the popup menu. -> i tried doing a copy & paste. 2. paste on the "autoupdate types folder" shows *4* different types of paste. The default one works as expected, but for example "paste->default instance" creates garbage.
This is at least P2. Each folder node in Options dialog has invalid set of items in popup menu (e.g. Refactor).
This defect has been fixed in main trunk. Probable regression caused by fix of issue 57270. Reassigned to Radek which asked for approval of fix 57405, which already fixes this.
Milos, please file new issue about Paste types in Autoupdate types. These problems are independent. Thanks
It works fine in trunk build (200504051800)
No, No - #57270 definitely doesn't have nothing to do with this report. This issue looks like duplicate of #57404. Definitely: SettingChildren.java revision 1.27 solves this problem. Jesse, please could you look at it.
*** Issue 57553 has been marked as a duplicate of this issue. ***
Main bug might have been dupe of issue #57404, but I am not sure. Reassigning to Milos to investigate the Paste issue, lower priority. Raise priority of issue #57404 if you want a fix in 4.2.
saubrecht in issue #57553 seems to claim that SettingChildren.java 1.27 *causes* this problem. Not clear what is going on. Anyway, the place to start is to do a clean compile of core (or Find Usages) and check for all usages/overrides of deprecated Node.getActions(), Node.getDefaultAction(), and AbstractNode.setDefaultAction(), since this was to blame in issue #57404.
FWIW I see several deprecated usages in core and core/* modules as well as openide, which ought to be fixed regardless of whether they cause apparent problems. These methods have been deprecated for quite a while now; there is no excuse to still be using them in core. Don't forget Node.getContextActions() and AbstractNode.createActions, too.
I am confused from decreasing of the priority and it is not clear to me what relationships are among issues mentioned at this page. IMO this issue should be fixed in release 4.1. There are broken actions in Options dialog and some actions may cause confusing behavior. I know at least about these: 1.Copy & paste as described Milos. 2.Refactor actions. When I have e.g. Main class opened in the source editor then open Tools|Options dialog and invoke popup menu on e.g. System node I see Refactor item there. Pushing Refactor|Rename causes not rename of the node but Rename of the Main class in editor (other refactor actions work similarly). I think this is not the behavior that can stay in release 4.1.
i have fixed this for menu and toolbar nodes in the options dialog. Checking in ToolbarFolderNode.java; /cvs/core/windows/src/org/netbeans/core/windows/services/ToolbarFolderNode.java,v <-- ToolbarFolderNode.java new revision: 1.9; previous revision: 1.8 done Checking in MenuFolderNode.java; /cvs/core/windows/src/org/netbeans/core/windows/services/MenuFolderNode.java,v <-- MenuFolderNode.java new revision: 1.6; previous revision: 1.5 done
just a follow up to my previous comment - the real problem was issue #57404 (overriding of deprecated method)
I wonder why I ended up owning this issue. I've created a separate issue for paste types: #57657 I don't understand if the problem is fixed or not, or who is responsible for it, reassigning to jrechtacek since he was the original person to be assigned this bug and Standa fixed it for menu and toolbars for autoupdate types should be still broken.
I'm a little confused. It's a general problem with actions on Options nodes. Does somebody plan to fix it in NB4.1? It was initially file against to autoupdate module (and to me as its owner) but was figured out that in not autoupdate problem. Should I continue to fixing this? Or someone else?
As Jarda Uhrik this issue still exists in release4.1 and is even more ugly (actions on nodes in Tools/Options) than it was in previous releases.I tried to find out the original cause. Here is my result: User: jglick Date: 05/03/30 13:54:08 Modified: /openide/src/org/openide/nodes/ BeanNode.java /openide/loaders/src/org/openide/loaders/ XMLDataObject.java /core/src/org/netbeans/core/ui/ ModuleNode.java, LookupNode.java /core/src/org/netbeans/core/ LoaderPoolNode.java /core/settings/src/org/netbeans/modules/settings/convertors/ SerialDataNode.java Commited before reease41 branch was created. Right, but involved next fixes that went just into trunk. SettingsChildren rev. 1.7. Next fixes went also just in trunk MenuFolderNode and ToolbarFolderNode fixed by Standa (unluckily he used again deprecated method createActions for his fix). The easiest and safest fix for release41 is to rollback (AFAIK): - LookupNode rev. 1.32 (cvs update -j 1.32 -j 1.31 LookupNode.java) - ModuleNode rev. 1.36 (cvs update -j 1.36 -j 1.35 ModuleNode.java) Reassigned to Jesse.
So AFAIK fine in trunk. Could QA please check that the proposed patch (reverting LookupNode.java 1.32 and ModuleNode.java 1.36) fixes observed problems in release41, whatever those are?
The proposed patch looks fine. So you can revert the changes in 4.1.
Diffs (read them backwards, old -> new): http://www.netbeans.org/source/browse/core/src/org/netbeans/core/ui/LookupNode.java?r1=1.31&r2=1.32 http://www.netbeans.org/source/browse/core/src/org/netbeans/core/ui/ModuleNode.java?r1=1.35&r2=1.36
Checking in core/src/org/netbeans/core/ui/LookupNode.java; /cvs/core/src/org/netbeans/core/ui/LookupNode.java,v <-- LookupNode.java new revision: 1.32.2.1; previous revision: 1.32 done Checking in core/src/org/netbeans/core/ui/ModuleNode.java; /cvs/core/src/org/netbeans/core/ui/ModuleNode.java,v <-- ModuleNode.java new revision: 1.36.2.1; previous revision: 1.36 done
verified in NB4.1(200504171930)