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.
With 6.0 jVi used NbEditorKit.undoAction. This started working strangely in 6.1. This is with a .java file, not sure about others. Using the toolbar undo/redo works as expected. While investigating the problem, I see that in 6.1 there are *two* UndoableEditListeners on the JEditorPane's document. (there was only one in 6.0). The NbEditorKit.undoAction operates on the other/new UEL. Actions/Edit/org-openide-actinos-UndoAction.instance works on the original/old UEL. I'm filing this bug because I'm guessing there shouldn't be two listeners. And in addition NbEditorKit.undoAction does something different that the toolbar undo button. I notice that editor kit action now checks for a UNDO_MANAGER_PROP on the document, maybe that got set wrong. Changing jVi to use the file system's action fixes jVi's issue and works with both 6.0 and 6.1, but I'm a little confused as to what's going on and if always using the system action is correct?
Hi Ernie, this is caused by my fix of issue 118038. Excerpt: ------------------------------------------------------ The code in form editor's FormUtils which sets an undo manager and undo/redo keybindings was disabled. It did not restore the state of the editor component's keymap and since the keymap instance was shared among the editors this problem arised. Editor now manages its own default undo manager in case when it's not added into a TopComponent so the functionality in FormUtils is no longer needed. A nice side effect is that the undo/redo should now also work in other editor panes embedded in dialogs e.g. in debugger's Evaluate Expression dialog. http://hg.netbeans.org/main/rev/4a5981146d70 ------------------------------------------------------ IMHO the change is desirable since it allows the editors embedded in dialogs to have a working undo without any extra work (creating undomgr/actions/keybindings). There should however not be two UE listeners at a same time. The default one should be disabled once the editor gets added into a TopComponent and NbDocument.CustomEditor.createEditor() gets called - the EditorUI.checkUndoManager() should be invoked. Generally you should find the undo/redo action by name and invoke its actionPerformed() and it should pick the right impl and functionality.
Howdy Milos, I think I understand what you're saying and it certainly makes sense, for example jVi works with the evaluate expression dialog (though there are some ESC issues) and undo would be nice. I can't reproduce what I saw, not sure how I got into that state. (I did see two undoable listeners or I would never filed this bug) If I'm understanding, the statement "Generally you should find the undo/redo action by name and invoke its actionPerformed()" doesn't seem correct. It seems like the right thing to do is use NbEditorKit.undoAction since it checks for the UNDO_MANAGER_PROP and if not found then does the system action. If I call the system action directly, then I'm guessing undo in EvalExpr won't work.
Regarding the undo action's finding (by name) I've meant the same thing like you are describing. Assuming I have a BaseKit's descendant the correct way for searching all actions is IMHO: kit.getActionByName(BaseKit.undoAction).actionPerformed(...) which (assuming that the real kit is NbEditorKit) will find NbEditorKit.NbUndoAction since NbEditorKit.createActions() redefines the undo action.