Seperate undo buffers for edit mode and run mode

[altenbach]

Currently, there is exactly one undo buffer for everything.

Scenario: I make a minor code edit,

... then run the VI to test if we get the correct result for a variety of control settings,

... and then stop the VI and decide that we actually don't want to make the code change (e.g. because the results are wrong!).

--> for some reason, we need to press ctrl+Z many (many!) times, because first we need to "undo" all the control changes during runtime.

I suggest that two undo histories should be kept, one for edit changes and one for runtime changes.

In the above scenario, pressing ctrl+z after stopping the VI would immediately start undoing the edit operations.

Message Edited by altenbach on 09-04-2009 08:20 AM

[PJM_Labview]

Great idea. This has been "bugging" me for years.

[crelf]

It's a pity I can't kudos this more than once 🙂

[Sima]

Could we go further and split the undos into front panel vs block diagram changes?

[altenbach]

> Could we go further and split the undos into front panel vs block diagram changes?

Many editing changes change the BD and the FP at the same time (e.g. create a control or indicator), so I am not sure how to cleanly separate the two.

For example if you place a control on the FP, then go to the BD and press undo, should it delete the control?

[AristosQueue (NI)]

A) Are we talking about edits that the VI makes to itself while itself is running or are we talking about changes that running VI A makes to non-running VI B? 

B)

> In the above scenario, pressing ctrl+z after stopping the VI would immediately start undoing the edit operations.

If the last edit I made in edit mode was "make this text boldface"and the last edit I made while running was "remove the text", I have to undo the run time change before I can undo the edit time change. Right?

I can only think of two ways to implement this feature request:

1) When you hit the Run Arrow, you get a new front panel completely different from your editing window.

or

2) While running, every edit you make is fully logged by our transaction mechanism (which is slower than changes made without transaction logging) and as soon as you stop running, all edits made while running are instantly reverted. 

Both of these would have severely negative impact on the ability to use runtime state as the basis for further edits (such as making operate value into default value). 

Did I miss something?

[Intaris]

How about just giving us a drop-down list of the changes which can be undone and marking them somehow as run-time or edit-time so that we can select a whole bunch of them and undo them in one go.

Even without marking them as RT or ET a drop.down list for undo steps would be very welcome....

[labview4steve]

I posted this page because I didn't find this initially...

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/UNDO-Function-Have-a-separate-undo-for-the-front-panel...

Its basically the same as this one...

I suggested having two types of undo.  A Global Undo - which operates the same as the current. and a seperated undo that works on the front panel or block diagram that is currently active and visible...

also the front panel would have something like CTRL+Z + F for front panel

and CTRL+Z+B for the block diagram undo

[X.]

Kudo to Intaris (undo a la Adobe Photoshop, basically).