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.
The New Action wizard allows creation of a CookieAction that is sensitive to the Project.class. The Project class is one of the entries in the drop down in the wizard. When such an action is created, the action is enabled only when one selects a project node. So far so good in terms of functionality from user's perspective. However an astute user may observe that it is kind of strange because the Project interface does not implement Node.Cookie. Here is the problem. In the generated code of performAction() method: protected void performAction(Node[] activatedNodes) { Project c = (Project) activatedNodes[0].getCookie(Project.class); // c is always null } It always returns null project. It is possible to get the project using the following code though: Project project = (Project) activatedNodes[0].getLookup().lookup (Project.class); However the user may not know that. The problem seems to be related to the implementation of : private int resolveSupported(Node[] activatedNodes) method of org.openide.util.actions.CookieAction class which uses the lookup to detect enablement.
If the change to the default performAction body really works 100%, then I guess we should just make that change in the template. Otherwise I would prefer to remove Project from the list of recommended "cookies" until Yarda's actions work is ready.
Yes the following works Project project = (Project) activatedNodes[0].getLookup().lookup (Project.class); for project. The same API is used to enable the CookieAction.
> then I guess we should just make that change in the template. Do you mean to use the lookup just for the Project.class or for all classes/cookies in the combobox. Seems that by default lookup delegates to cookie, so for all cookies?
Of course we would prefer to use getLookup().lookup(...) rather than getCookie(...) for all cases, assuming it works. (It should - but needs to be tested.)
1. Use getLookup().lookup(...), it should work (unless people provide own lookup and also override getCookie which is strongly discouraged). Otherwise report a bug. 2. When using getLookup, is it really wise to subclass CookieAction, shall not one rather build on top of NodeAction 3. I'll provide some simplified action apis for 6.0. I promise.
Re. #2 - well. The problem is when the lookup for the currently selected node changes. When using NodeAction you will never have enablement recalculated. When using CookieAction you will have it recalculated if the interface in fact extends Node.Cookie; whether it works if it does not, I don't know.
Hmm...I am starting to think that CookieAction will be a misnomer if we use Lookups for the implementation. As it is it did confuse me when I saw the Project in the list of cookie classes combo box in the New Action Wizard - knowing that Project does not implement Node.Cookie. Should a new LookupAction sub class of NodeAction be created intead whihc is purely Lookup based? Just a thought.
For 6.0 we are planning a completely separate set of base classes / supports for actions which will address this. In the meantime I think CookieAction is the closest existing support for lookup-sensitive actions, despite the name.
ui/wizard/action/DataModel.java; 1.21 -> 1.22;