Undo Limited by Steps or Memory

[Manzolli]

Since nowadays machines with 4 GB or more became very common, the undo function limit could be have the option to be set by memory amount instead of steps. In memory mode, there will no steps limit.

[RavensFan]

How many steps (or memory) of undo do you think you need?  LV now has the ability to go to 99 steps of undo.  That should be more than enough.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/The-CTRL-Z-Undo-should-have-more-steps/idc-p/1009450

[Manzolli]

Many times we do some changes on BD, run for a test, interact a lot with the FP (increase, decrease, etc.) and figure out that some changes should be undone. But when you try to undo you ran out of steps not because of the changes in the BD. Making two separate buffers would be nice.

But, why limit the amount of undo steps to a outdated value? If my system has enough memory, just let the undo buffer use it up to a point I choose according to the available resources and my personnel needs.

[altenbach]

> But when you try to undo you ran out of steps not because of the changes in the BD. Making two separate buffers would be nice.

This has been addressed with my old idea of keeping seperate undo buffers for edit changes vs. rutime changes, but according to the discussion, there could be some technical issues.

The current implementation of the undo buffer is not perfect, and the number of undo steps is not going to fix it. In my typical use I am hitting the wall not because of limits in the undo steps, but because certain operations clear the undo buffer (poof!) and certain changes don't get entered into the undo buffer. (For example, make a small xcontrol that has mosts controls/indocators outside the FP window boundary because it has to look that way. Now double-click one of the terminals on the BD: The FP pans to the hidden control and undo won't pan the FP back to where it should be. (Of course this issue would be better adressed by another idea)).

There are also other events that can kill your VI, e.g. program crashes, memory corruptions, etc., so an unlimited undo buffer could make you skating on thin ice. It is more important to save at regular intervals and make sure autorecovery is enabled. If you save your VI at important steps under a new name, all you need is a "file...revert" to go back all the way to the last mark.

I also object to the idea that 4GB of memory is "infinite". The programming environment has a duty to be as lean as possible in order to allow large data structures at runtime. Can we have some numbers? Is the main concern for limiting undo steps really memory? How much memory does an undo step really take?

Having a couple of projects open (several application instances!), running several LabVIEW versions at the same time and a couple of browser windows (IE8 seems to make a new process for almost every window/tab) often brings me close to the memory limits without doing anything special. 😉

[Manzolli]

"I also object to the idea that 4GB of memory is "infinite". The programming environment has a duty to be as lean as possible in order to allow large data structures at runtime. Can we have some numbers? Is the main concern for limiting undo steps really memory? How much memory does an undo step really take?
 
Having a couple of projects open (several application instances!), running several LabVIEW versions at the same time and a couple of browser windows (IE8 seems to make a new process for almost every window/tab) often brings me close to the memory limits without doing anything special."
 
Actually my computer has 8GB running Vista 64, and normally I use to open two LabVIEW projects at same time at most, with many other software. Rarely I have more than one version of LabVIEW opened. This is my reality. Every one has a different one. Why the amount should be limited a 5+ year old specification not the user?
 
Giving an option to determine the maximum memory allocation, it can represent 500 steps or only 50. The current way of limiting by the number of steps can make your run out of precious memory in just a few steps, for instance deleting a 3D graph indicator with a huge amount of data in it.
 
There is another software that I use both steps and memory limitations to avoid major problems. The nice thing is that you can change the default behavior and values as you wish. I'm using 250 steps and no memory limit. I never reached the bottom. If one day it happens, I just increase the number of steps.
 
I never run out of memory in this computer (the maximum allocation I saw was about 3.6 GB, right now it's 2.8GB with 9 applications + environment: O.S., drivers, antivirus, etc.). Sometimes opening lots of applications can make my computer run a bit slower, even though is quad core. Then I check "who is the hungry one", close some stuff to keep working fine.

[G-Money]

I'm sure there was some reason for keeping the undo stack to just 99 but I would like to see the reasoning for it especially with the prevalence of more and more higher RAM machines in use.

[Darren]

Any idea that has received less than 3 kudos within 3 years after posting will be automatically declined.