Undo improvements suggestions

[X.]

I have started a post in the LabVIEW forum to probe the water first. It seems to have caught some momentum, so I am upgrading it to a suggestion.

The undo function was like the iPhone of the late 90's. There was a before and an after.

More than 10 years later (this is not an accurate statement), it may be time to revisit it and adjust a few "features":

1. When undoing something that affect a part of the diagram that is not shown (whether because it is out of the screen (bad programming practice, all right) or because it is hidden in another case, it would be nice to move the focus to that part of the diagram.

  Not seeing that something has been deleted (and added back when you undo) is not very informative.

  Marching-ants or ghost contours for a piece of code that has been deleted on case XXX when you are looking at case YYY is not very informative.

  In fact, both are potentially very misleading.

2. The undo function undoes everything: motion of objects, rescaling, deletion, addition, etc... and it undoes that on the FP and BD. That makes sense if you are dealing with a control, but that does not make much sense if you simply nugded a decoration. See where I am getting at (as many other have before)? We need control on what is undone. And the best interface so far for an undo HISTORY is to have a specific panel in which you can browse the different actions and select which one you want to undo (or limit the scope to innocuous actions such as reshaping things, etc...rather than logical one like deleting, replacing, etc...).

Since I am not claiming paternity of any of this, I leave this list open and invite people to add to it (or link to their own suggestions for the kudo-hunters). Bottom-line, it's time for a redo of the undo...

[Manzolli]

Nice ideas. I agree that the undo can be better and it's time to change it. Here some extra/complementary ideas:

1) I would like to have the undo attached to the window in focus. If I have 2 open VIs, the system should have 4 undo stacks, one for each possible window.

2) Expanding the above idea, for each VI being edited the system creates 3 undo stacks: FP, BD and FP values. It's a pain when you change a value in the BD using increment/decrement and each step becomes one undo.

[AristosQueue (NI)]

> 1) I would like to have the undo attached to the window in focus. If I have 2 open VIs, the system should have 4 undo stacks, one for each possible window.

Restating another way: Each VI today has its own undo stack. If I have 2 open VIs, I have 2 undo stacks, which means if I make changes on two successive VIs and then go to the first one and hit Undo, LV undoes the change to that first VI, not to the second VI. What you are asking for is to separate the undo stack for the block diagram and the front panel of the same VI.

Speaking as a LV user, NOT as a LV R&D member:  I would find that confusing, myself. If I do "Create Indicator" on the diagram, then go to the panel and put that indicator on the conpane, and then go to the diagram and hit Undo, I don't think I want both the "add to conpane" and the "Create Indicator" being undone in a single step. The panel and the diagram interact with each other in enough ways that unifying the undo stack would be bad, in my opinion. Any difference of opinion probably depends on whether you see the diagram and panel as two completely separate entities or whether you see them (as I do) as two different views of the same VI object.

As an R&D member: Would many users prefer the experience of separate undo stacks? It's probably technically feasible, although there are some interesting situations of interaction between the two that might get complicated.

[AristosQueue (NI)]

I replied to just one side comment, not to the main idea. I realized that I should probably formally acknowledge the main idea as something I generally like.

[X.]

I don't think you necessarily want two undo stacks per VI. But having an information of where the action takes place would be helpful. The ideal full-blown interface is far away, but this might be a start:

Sorry for the quick sketch.

The idea is to have a "chronological order" (the first column) which you can sort in increasing or decreasing order (or just disregard).

The second column gives a short description of the Action. If an object is acted upon at different point in time (whether on the FP or BD), you can choose to group all actions affecting the same control by clicking a strategically located check box (as displayed here).

The other column provide more info and of course one could had many more.

I second the idea of being able to disregard control/indicator value changes made by the programmer (another check box or "scope list"?). Those are usually secondary when writing code.

You definitely want a good representation of what other actions are affected (will disappear) if you select one of the lines and press the "Undo" button (not shown). A tree representation may not be the best...

[altenbach]

Two related ideas:

UNDO Function: Have a separate undo for the front panel & Block Diagram

This has suggested part of your idea over a year ago and has not gained any traction. (0.25 kudos/month!).

Seperate undo buffers for edit mode and run mode

I would love that!

So you are doing some editing then run the code for a quick test and move a slider up and down and stop the VI. Pressing undo for a near infinite time moves the slider a small nudge at the time and the important editing changes have dropped off the end of the undo buffer. 😞 (...maybe each slider movement from key down to key up should only create a single undo entry?)

[Manzolli]

Good point Aristos. I forgot that the things in the FP are connected to the respective BD. Some changes affects only FP, others BD, others both. At least the data change made in the FP can have a separated undo stack.

[johnsold]

I can see the issues with FP and BD linkages.  I do not have a big problem with a single undo stack per VI.

However, I strongly agree that data changes should not generally be included in the undo stack.  The case of Make Current Value Default... after a data change may create some interesting issues.  Even there undoing the Make Default while leaving the data values alone should not be too confusing.  

If such changes are made, they need to be clearly documented in the Change notices and Help.

Lynn