I've implemented this in a separate branch (with the changes from my previous PR #262 already merged).

What's changed?

• Undo/Redo support for class creation/deletion/modification
• Undo/Redo support for changing nodes / node types / address etc.
• Added an undo/redo button pair to the toolbar using the existing icons already in the resources
• Defined some toolbar buttons for some node types to be able to overflow the toolbar if the window is narrow

I didn't implement undo/redo for enums as the enum functionality is a bit broken I think (there's an add event but not a remove event for instance. I had it working more or less but didn't want to add it just yet) so I left it as-is.

I added this using Algorithmia's command system. This is a library I wrote a long time ago and maintain since, and it's very stable. It comes with 2 nuget packages (algorithmia and bcl extensions).

The system basically tracks commands executed through the command queue manager and records every command in the 'active' queue on top of the stack. So when a command A changes something that executes a command B, B will end up in A's command queue and B's command queue is then put on top of the stack. This way you can track multiple commands within the scope of a single command and undo/redo them in 1 go. A command is an object with a lambda that makes a change and it has optional lambda's to obtain the pre-change state and the post-change state. Algorithmia has several datastructures that mimic BCL classes (like list) and wrappers (to wrap members to make them undo/redo aware) and they take care of change checking and event raising as well.

I have tested it with several class hierarchies and I think it works ok, but I know from experience that Undo/Redo code can get hairy at times especially in edge cases, e.g. multiple undo/redo sequences work ok but perhaps I missed an edge case and an event handler creates duplicate elements when redoing the whole tree of commands.

Let me know if you need additional info, or if I have to make additional changes :)

NOTE the commits in this PR are apparently also the ones in #262 :( Which sucks, and might be complicate file reviewing. If you want to wait reviewing this because of that, that's fine. I'm sorry this happened, I honestly don't know how to avoid that.