Omer van Kloeten's .NET Zen

Programming is life, the rest is mere details

News

Note: This blog has moved to omervk.wordpress.com.

Omer van Kloeten's Facebook profile

Omer has been professionally developing applications over the past 8 years, both at the IDF’s IT corps and later at the Sela Technology Center, but has had the programming bug ever since he can remember himself.
As a senior developer at NuConomy, a leading web analytics and advertising startup, he leads a wide range of technologies for its flagship products.

Get Firefox


powered by Dapper 

.NET Resources

Articles :: CodeDom

Articles :: nGineer

Culture

Projects

Things To Consider When Creating An Undo Mechanism

Brainstorming an undo-redo mechanism at work today and here are a couple of thoughts:

  1. There are so many mechanisms that already exist. A quick google on CodeProject gives five right away (without extra digging). NIH is foolish. :)
  2. Undo actions are transactions. However, they might not be just for your business objects, but also for your UI. An undo transaction might be only for the UI (but not likely).
  3. We've considered using Action/Reverse-Action, but this is double the code and development time. Reverse actions might also not be possible at times, since multithreading and events might cause non-deterministic action order.
  4. System.Transactions is nice, but it only works in one way - Undo. Creating a Redo with dual transaction directions might work, but it seems like a kludge.
  5. This article offers the closest solution to what we need, but it causes debugging pains and supports neither transactions nor UI element changes.

Anyone know of any good solutions?

Comments

No Comments