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.
We'd like to have the UndoRedo functionality retrofitted as a cookie. So the undo and redo actions are working also when other windows which doesn't affect the global activated nodes are still working (e.g. when is activated property sheet, and java source was before). The diff provides a way we did it. It is just a pointer. If implemented, there is no need to change the NbSheet, but just change the Undo and Redo actions to work with nodes instead of the TopComponents.
Created attachment 19708 [details] Diff of our impl
Why as cookie? Node.getLookup() can provide any object, not only cookies, and the way you did it forces all editors to provide access to their UndoRedo.
To the goal: Well, first let me describe what we need. We need the Undo and Redo actions to work also for cases when there is activated TopComponent which doesn't change activated nodes (returns null) are still working according to the global activated nodes. E.g. 1) Activated source editor component 2) Do some editing -> the Undo and Redo actions are enabled accordingly (are working) 3) Activate e.g. property sheet component 4) The Undo and Redo actions gets disabled (not working). We'd like to have them working when activated the ProrpertySheet. To the solution: Having the UndoRedo as cookie, is solution which was taken here, it is not the way we require to fix it. It just seems that if UndoRedo is a cookie, it would be easy to do, just to retrofit the Undo and Redo actions as cookie actions (or to work with the cookies, instead of TopComponent -> The TopComponent#getUndoRedo might be deprecated), create the simple UndoRedo cookie, and provide them by the CloneableEditorSupport/DataEditorSupport (which is already made). But of course you might use kind of solution, it is up to you.
The UndoRedo is provided by TopComponent. It is possible for property sheet to get it from the node's lookup. Why not. Just write a test (somewhere in core) that will show that PropertySheet top component correctly delegates to its activated node. Plus what happens when the node does not have the cookie and what when multiple nodes are selected.
When node doesn't have the cookie, the actions should be disabled, that is straightforward. The same I guess should be if there are more nodes activated while more than 1 provides the cookie (It would be confusing to undo/redo more things at once). Interesting is a case, there are more nodes activated, and only 1 provides the cookie. I'd guess also in this case the actions should be disabled, since it might be confusing too what is supposed to be undo/redo. I.e. I guess it should work only for the case, exactly one node is activated, and the node provides the cookie. Of course it is up to you to evaluate and take different policy.
Is it possible to modify this issue to type "Defect" as set it up for Target Milesonte "Dev". This seems to still be an issue and unfortunately our customers view it as a bug rather than an enhancement.
Reassigning to new module owner mslama.