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.
Summary: | A way to listen to UndoableEdits (was: UndoRedo - No ChangeEvent published to listeners) | ||
---|---|---|---|
Product: | platform | Reporter: | prunand <prunand> |
Component: | Window System | Assignee: | issues@platform <issues> |
Status: | STARTED --- | ||
Severity: | blocker | CC: | jtulach, tboudreau, tomwheeler |
Priority: | P3 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Attachments: |
Example of UndoRedo ChangeListener bug.
Includes a modified UndoRedoManager that issues ChangeEvents when undoable edits are added. |
Description
prunand
2007-10-26 18:21:34 UTC
UndoRedo interface&impl is part of o.o.awt. FYI, the code that publishes the events is really weird and complicated (it looked like it might work but probably someone could subclass and break it). It looks like it was once intended to be multi-threaded (creates a runnable, etc.), and someone then changed it to run inline. Probably should be rewritten to do the obvious thing of just firing an event when an undo event is added/removed. Reporter, could you attach runnable source code of the module so that I can reproduce, test and debug? Strip any unnecessary code which is irrelevant for this bug, of course. Thanks. prunand, please attach requested info and then reopen, thanks. I plan to create you a concise example today. I'll post it shortly. Created attachment 52140 [details]
Example of UndoRedo ChangeListener bug.
Sorry for the delay. Here is an example. Click on "Undoable editor" under Window. There is a text field that adds UndoableEdits to the UndoRedo.Manager for the topcomponent. There is also a textarea where events are logged to. As UndoableEdits are added to the topcomponents UndoRedo, they are logged to std out, and to the text area. The same should happen as the state of the UndoRedo.Manager is changed, but this never happens. x I am not sure if my comment is relevant, but void UndoRedo.addChangeListener(ChangeListener l) javadoc says: Add a change listener. The listener will be notified every time the undo/redo ability of this object changes. Just by adding some UndoableEdit to the manager, there is often no change as canUndo and canRedo still return the same values. That is why there is no reason for any change event to be fired. This is probably my misunderstanding then. What is needed is a way to be notified when a new undo event appears - in order to support global undo-redo (not tied to TopComponents) and allow components with their own existing UndoRedo.Manager to have their undoable events published into a global undo- redo manager (which some custom Undo/Redo actions would work with). So do I understand correctly that we need new API, something like new interface UndoRedoEdits with add/removeUndoableEditListener? Or isn't it possible to use javax.swing.undo.UndoManager and its addUndoableEditListener(...) somehow? Changing to enhancement and updating summary then, please correct me if I'm wrong. This still seems broken to me. From the Class description of UndoRedo.Manager: "An undo manager which fires a change event each time it consumes a new undoable edit." This is of course in addition to the addChangeListener() description. The UndoRedo.Manager is not issuing any change events when its state changes. A new API may be what you have to implement, since there may be some backward compatibility problems, but then the old API should be marked as deprectaed and commented as broken. Also, I don't think UndoableEditListener is the right API to model after, since this is a listener to register to consume UndoableEdits from objects that may produce them (such as Document). I'm going to pull in the UndoRedo.Manager code into my example, and see if I can make it bend to my will. I'll report back with what I find. The source for this is actually very small. It looks like the sole purpose for this class is to support the addition of changeListeners. The code seems to make the assumption that users of this class will be issuing UndoableEditEvents in order to modify the Undo/Redo stack. My code was directly adding UndoableEdits via the addEdit method. This seems like merely an oversight in UndoRedo.Manager. I made a small change to fire change events if addEdit is called. The method I added is simply: @Override public synchronized boolean addEdit(final UndoableEdit anEdit) { final boolean retval = super.addEdit(anEdit); cs.fireChange(); return retval; } It may be more appropriate for me to issue UndoableEditEvents than my current implementation. I'll do some more testing, and post a new example with the change later today. Created attachment 52425 [details]
Includes a modified UndoRedoManager that issues ChangeEvents when undoable edits are added.
Oops, thanks very much for the contribution, I somehow overlooked it. I think it could be integrated as it is (your proposed fix), we just need to note the change in api changes for the module. prunand, could you make a patch (diff) for me? I think I understand what needs to be done, but it will be safer this way, as I'm not familiar with UndoRedomanager code, thanks. |