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.