Your code looks OK, although reusing an existing Changed SubHint (GoText.ChangedText) is not a good idea. Use something bigger than GoObject.LastChangedHint.
I changed the SubHint constant to “GoObject.LastChangedHint+666” and got rid of the view.ReportObjectEdited call and still don’t hit my ChangeValue event handler.
After the user has finished editing the field value, use the debugger to look at the GoDocument.UndoManager.EditToUndo, which should be a GoUndoManagerCompoundEdit. Then look at the last edit in the GoUndoManagerCompoundEdit.AllEdits list. Is its SubHint == your ChangedValue constant? Does it have the old and the new string values?
By the way, how is your EditValue method being called?
The string I specified in the FinishTransaction call is what I expect, but the subhint (1001) and the old and new values (null) are wrong.
I have improved my object constellation, but I still don’t get proper Undo/Redo behavior. All of my side-effects get undone/redone, but my primary changes are not logged in the GoDocument.UndoManager.EditToUndo edits list and are not performed on undo. Is this because my class does not implement the IGoControlObject interface? The “fieldDialog” is launched by the user by double-clicking on a GoText which signals the “GAPInputField” to perform an edit.
Your call to GoObject.Changed should be adding a GoChangedEventArgs onto the current GoUndoManagerCompoundEdit that the GoUndoManager maintains as document changes occur. I can’t explain why that call isn’t recording anything in the undo manager.
Okay, the GAPInputField was not part of the document. I’ve explicitly added it and now my UndoManager does what I want. Thanks!
If your GoGeneralNode-inheriting class has a collection of objects for which you want to implement support for undo/redo, I suppose you could use GoObjects to store that data. But it isn’t natural, since GoObjects are naturally meant to display something in a GoView, and the predefined subclasses of GoObject cover all of the basics already. And adding those GAPInputFields as top-level objects in your GoDocument may cause other problems, such as affecting the bounds of the document, and causing any code that iterates over the objects in your document to worry about those random-looking GAPInputFields. To summarize, adding GAPInputFields as random GoObjects to your GoDocument may cause headaches down the road.