- We inherited an object called "MysubGraph" that inherits form GoSubGraph.
- We override the DoExternalDrop of the GoView
- call base.DoExternalDrop then check if the dropping point is inside one of our "MysubGraph" remove the object from the GoDocument, then add it to our SubGraph Collection "MysubGraph".
It sounds like you have it working, except that undo and redo don’t appear to work correctly for those drops.
Did you do all of the document (removal of selected objects and addition into subgraph) changes within a transaction? For example, take a look at the AddSupervisees method in GraphView of the OrgCharter sample. That method does the actual work, called from DoExternalDrop.
Thanks for your fast response . I really apperciate
I had a look on the example you said about , I use a similar procedure ,creating an instance from the object and add it to the subgraph and these steps are encapusalted inside Start Transaction and Finish Transaction…But the undo and redo still don’t work.
A sample of my code is provided below:
// note this is the inhereted Subgraph
GoInhertedNode myNode = new GoInhertedNode();
Could you be more specific about what happens wrong when the user does an Undo or does a Redo?
There are several typical problem situations.
- Some changes are made to the document or its objects not inside a transaction. This causes all of the recorded changes to be associated with the previous transaction during an Undo, but with the next transaction (which might not have happened) for a Redo.
- Transactions aren’t ended or are nested incorrectly–i.e. the GoUndoManager.TransactionLevel isn’t zero when you’d expect it to be. Then CanUndo() and CanRedo() will be false, so the user can’t do either operation at all.
- SuspendsUpdates or SkipsUndoManager is turned on for either GoDocument or for a GoObject at an unexpected time.