Undo saves unuseful states

JGo
1
Hi,
I noticed that JGo saves the move events for all objects when I move the selection with the mouse. It can use really too much memory for nothing.
For example, you can have an OutOfMemoryError in the Demo1 example by moving in circle a lot of nodes during 1 or 2 minutes.
In my application, I can have easily 50 JGoView with their UndoManager, so I can't let the UndoManager stores unnecessary objects.
I did this patch on my objects to prevent it :

@Override

public void handleMove(JGoView view, int modifiers, int event, int spotNumber, int origX, int origY, int newX, int newY) {

boolean bSkip = isSkipsUndoManager();

boolean bSkipDoc = getDocument().isSkipsUndoManager();

if (event == JGoView.EventMouseMove) {

setSkipsUndoManager(true);

getDocument().setSkipsUndoManager(true);

}

try {

super.handleMove(view, modifiers, event, spotNumber, origX, origY, newX, newY);

} finally {

setSkipsUndoManager(bSkip);

getDocument().setSkipsUndoManager(bSkipDoc);

} }

Another problem I have is when I moving some nodes with the keyboard. It will be really nice if when I move 10 times a node by pressing on the keyboard, it can aggregate the moves.

Thanks in advance,
Alexandre Pique
2

Actually, we used to do a similar optimization in JGoView.doMoveSelection, rather than in some JGoObject method. However, it wasn’t quite perfect, since there were various special cases that couldn’t be optimized by turning on JGoDocument.setSkipsUndoManager.

[By the way, if you set that property on the document you don't also need to set it on a particular document object.]
The problem with trying to "aggregate" moves invoked repeatedly, such as by a keyboard command, is that you have to assume that it can be undone at any time after each move. Doing such optimization would mean that four down-arrow keys to move the selection could not be undone with four ctrl-Z's. That might be OK for your application, but I find such optimizations unsettling.
One possibility is to override JGoUndoManager.addEdit in order to perform optimizations. You could scan the list of JGoDocumentChangedEdits in the compound edit that is being added, and remove all of the intermediate ones that you can prove are superfluous. And you could look at the previous edit (if any) and see if it or part of it could be combined with the new edit, if you don't mind merging transactions.
3

Hmmmm… I was having the same problem and from Walter’s post was wondering if it was correct to override the JGoView.doMoveSelection() method.

Here is what I did:

public void doMoveSelection(int mod, int offx, int offy, int evt )
{
// Absorb any extra “MouseMove” events
if (evt == JGoView.EventMouseMove) {
getDocument().setSkipsUndoManager(true);
}

    // Send any other events to the default handler
    try {
        super.doMoveSelection( mod, offx, offy, evt );
    } finally {
        getDocument().setSkipsUndoManager(getDocument().isSkipsUndoManager());
    }
}