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.
In our application (the XSD editor in xml/schema/core) we have both a graphical editor view of the document model, and the source editor view (inherited from CloneableEditor). Due to the complexity of managing undo/redo events between the two views, our solution involves two undo queues, one for the graphical editor, and one for the source editor (the CloneableEditorSupport undo/redo manager). The trouble comes when we want to manage the dirty state of the data object. In CESUndoRedoManager the callNotifyModified() and callNotifyUnmodified() methods are called. However, these are package-private, so our own editor support subclass cannot access these methods. Subsequently, we are stuck with one of two diffirent problems that cannot be solved. The only work-around for us would be to copy all of the CES code and change two lines to suit our purposes. In short, what would solve our problems is for the callNotifyModifed() and callNotifyUnmodified() methods to be made protected, so they can be accessed by subclasses.
There is at least one other reason why this issue is important. Take for instance the fact that CloneableEditorSupport allows you to create your own UndoRedo.Manager instance (via createUndoRedoManager() method). Now notice how the methods and fields that the private inner class CESUndoRedoManager utilizes are themselves private. So, while a subclass can make its own manager, it can never get the same behavior as the private inner class. This is because CESUndoRedoManager can access the package-private methods of CloneableEditorSupport, but the subclass could never do that. Now compound this problem with the fact that the multiview support lets you have an UndoRedo for each multiview element. This conflicts with the suggestion from Yarda that we should only be using a single manager (see issue 80586). Since it is quite common to have a source editor as one of the multiview elements, this problem will come up over and over again.
This fix is needed by EntPack Team
The requested change is unsystematic and would cause more harm than good. As was already explained in issue 80586, the correct approach is to keep feeding changes into single undo manager. The fact that multiview allows you to have separate UndoRedo for each element is an unfortunate API overlook. Multiview is intended to allow more _views_ over single model of some kind, so modifications from all views should affect that single model and the undo queue should be related to that model, not each visualization of that.