We did something similar with our financial application, therefore all financial transactions can be canceled and all their impact (from registration to accounting) can be undone.<br>You can read a little bit about this in the Command pattern documented in the GOF<br>
<br>Bye,<br>Hernan.<br><br><div class="gmail_quote">On Wed, Apr 16, 2008 at 1:06 AM, tim Rowledge &lt;<a href="mailto:tim@rowledge.org">tim@rowledge.org</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
On 15-Apr-08, at 8:46 PM, Colin Putney wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
<br>
The usual way to do this is to have all your undoable units of work be implemented by &quot;command&quot; objects that know how to perform a specific action. Then when the user does something undoable, you create a command, execute it, then push it on the undo stack. To undo you can either have the command know how to undo its self, or have it create an &quot;inverse&quot; command. This kind of thing works pretty well, and it can be extended with other features like redo, logging, journal-and-snapshot persistence etc.<br>

</blockquote></div>
That&#39;s pretty much what we did in Sophie. It&#39;s non-trivial but then the problem domain is non-trivial.<br>
<br>
tim<br><font color="#888888">
--<br>
tim Rowledge; <a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" target="_blank">http://www.rowledge.org/tim</a><br>
A sad tale that brings a lump to the eye and a tear to the throat.<br>
<br>
<br>
<br>
</font></blockquote></div><br>