I have a custom method to create (and automatically link) nodes in a chain. Each ‘link’ in the chain is its own document transaction. Each transaction contains both a JGoBasicNode creation and a JGoLink creation, except the caboose link in the chain, which obviously contains just a node.
When I undo, it undoes each link in the chain individually, as expected. When I redo, it puts them back. However, after being redone, the front end of each JGoLink is no longer connected to the BasicNode in front of it - when I attempt to move the BasicNode, it disconnects.
If I move the node that the tail of the link is connected to, and the connection was never severed via undo/redo, it snaps back onto the link it was broken from. Then if I move the head node, it breaks again.
I don’t understand why the link can think it’s connected to both ports (head and tail) correctly when you move a node whose creation was not undone/redone, but when you move a node whose creation was undone/redone, it no longer thinks it’s connected to the tail only.
Do you guys know what I’m missing? I’m hoping that it is something you have seen before with a quick answer. I’ll describe the way I’m creating the transactions if you’ve never seen this symptom before.
Well, I don’t know for sure, but perhaps when you were building it programmatically with transactions, you made some changes that you wanted to be able to undo in a manner that they didn’t get recorded in the UndoManager.
Typically this happens when you make a change to something when it is not part of a JGoDocument (with an UndoManager and with SkipsUndoManager turned off, of course).
So if you connect a link to a node that isn’t already in a document layer, that connection can’t be recorded, since there’s no accessible UndoManager. Really, if you care about being able to undo/redo, you should construct and add the node(s), then construct and add the link(s).
I hope this addresses your particular problem.
I construct a hovering node which is not in the document yet, as it is only a visual cue, and stuck to the mouse. i also construct the link linking the hovering node to the previous node, which is in the document.
[code]
//start the transaction for the next node in chain (hoveringNode) but
//it will not be finished until it is placed (next time this method
//is called, which delagates to placeFinalNodeInChain)
view.getDocument().startTransaction();
hoveringNode=new BasicNode();
hoveringNode.setLocation§;
hoveringLink = new Link(prevNode.getPort(), hoveringNode.getPort());
hoveringLink.setArrowHeads(false, true);
//only put it in the view for now - it's 'phantom' until it is placed
view.addObjectAtTail(hoveringNode);
view.addObjectAtTail(hoveringLink);[/code]
then later (after a lot of mouse movement) we need to place the phantom node and link (which are following the mouse pointer) into the actual document…
hoveringLink = new Link(hoveringLink.getFromPort(), hoveringLink.getToPort());
hoveringLink.setArrowHeads(false, true);
view.getDocument().addObjectAtTail(hoveringLink);
view.getDocument().endTransaction("insert and link node in chain");
RMNode oldHoveringNode = hoveringNode;[/code]
hoveringLink is actually still valid from its creation before (it was stored) - but I am reconstructing the link to trick the undoManager into seeing it?
is this code correct? i’m still tracking down this bug but it might be somewhere else in the code.
I wouldn’t think that you should have a transaction involving adding or removing objects to the JGoView. It’s when the user is done, just before you start modifying the document, that you should start the transaction. However, I don’t think that change would affect the undo/redo behavior you are seeing.
Removing the “hoveringNode” from the view will remove all the connected links, including links owned by the view. However, since you are making sure the link is connected to the desired ports, in this case by just creating a new link, that should be OK.
So your code looks OK, particularly if you minimize the scope of the transaction to the minimum time when modifying the document at the end of the user action.