Implementing infinite undo/redo (Matt Gertz)

re: Implementing infinite undo/redo (Matt Gertz)

VBTeam — Fri, 06 Feb 2009 01:08:41 GMT

Not off the top of my head, Freud. In practice (or at least in my experience), the stacks don't build up a lot of undos before they get flushed by the opposite action followed by new content, so we never really see much inefficiency. Our own undo-redo stacks in Visual Studio basically work the way I've detailed them in this blog, and while we have a number of performance or memory issues that we concentrate on, this hasn't been a problem areas. Limiting them to some arbitrary number is, as you say, even problematic. (The only reason to do it is in low-memory cases, and that's just not an issue in these days.)

re: Implementing infinite undo/redo (Matt Gertz)

freud — Thu, 05 Feb 2009 19:08:55 GMT

I'm using a LIFO Stack(Of ) without limit, but i think that in a long day of work this could be so much inefficient. And the idea of limiting a stack (to twenty i.e.) could even be more inefficient, because the action of pop the last element causes: pop the n elements and copy to another one( or an array), eliminate the bottom of the stack and then copy the rest back to the stack, and repeat this procedure for any undo action that the user perform.

Any better idea ?

How to Do Cool Things in Visual Basic

Computer Science Teacher - Thoughts and Information from Alfred Thompson — Fri, 20 Jul 2007 00:14:54 GMT

OK here's the deal. If you are teaching Visual Basic, programming in Visual Basic for fun or profit,

How to Do Cool Things in Visual Basic

Noticias externas — Thu, 19 Jul 2007 11:33:55 GMT

OK here's the deal. If you are teaching Visual Basic, programming in Visual Basic for fun or profit

re: Implementing infinite undo/redo (Matt Gertz)

VBTeam — Tue, 10 Jul 2007 21:50:41 GMT

Bill: You are absolutely correct, I am abusing ListOf to be a stack here. When I wrote the code, I was actually adding it to the end of the list, and then said, "Well, I don't want to always be figuring out what the last element in the list is, so let's be lazy; I'm not going to have to pop the stack very often." But of course I am inserting fairly often, which is indeed inefficient. It's a very easy fix which I will take care of before I publish the final version later this week -- thanks for bringing this up. I'll add a note in the blog.

Aaron: Thanks, you are also right. That was a copy error from some if/then logic that got left behind -- I had gotten the whole thing working using conditionals, and then said "Well, that's stupid -- let's just use the value directly -- but then forgot to complete it for the second line. D'Oh! I'll repair that one in the blog itself.

Link Listing - July 9, 2007

Christopher Steen — Tue, 10 Jul 2007 05:27:38 GMT

The Distributed Observer Pattern | The REST Dialogues [Via: (author unknown) ] PainlessSVN - Subversion...

re: Implementing infinite undo/redo (Matt Gertz)

Aaron — Mon, 09 Jul 2007 20:28:03 GMT

Thanks, good series. I think there might be bug in:

Me.ShowSolution = Not Me.ShowSolution

Me.ShowSolutionToolStripMenuItem.Checked = False

Me.Invalidate()

I think the middle line ought to be:

Me.ShowSolutionToolStripMenuItem.Checked = Me.ShowSolution

Otherwise, the menu item never gets checked.

Thanks,

Aaron

re: Implementing infinite undo/redo (Matt Gertz)

Bill_McC — Sat, 07 Jul 2007 09:05:51 GMT

Inserting into the start of the list and then removing from the start of the list is really inefficient. It causes array copies for the entire amount in memory effectively doubling the memory requirement and increasing garbage clean ups.

The sotrage you use should be one that is optimised for Last In is First Out (LIFO), which would be a Stack(Of T)