Automatic operations (e.g. auto grow) should have their own undo entry.

[altenbach]

(This is a derivative of my comment here, but I think it deserves its own idea).

Sometimes the autogrow feature of structures does annoying things. For example if we create a control on the stop terminal of a while loop, the while loop sometimes grows downwards, even though there is plenty of space to accommodate the terminal a bit higher up in the existing loop bounds. When I encounter this, I usually select the new control, do a ctrl+x (to cut the new control), followed by a ctrl+z (to undo the resize and control creation), click elsewhere followed by a ctrl+v (to paste the control where I actually want it). Similar if I paste a sizable code selection inside a structure, the insert point might not be exactly centered on the empty space, causing a structure resize, even if the content would fit nicely if moved a little bit to the right or left.

My suggestion is that the autogrow operation should have its own entry in the undo buffer, meaning that (in the above first scenario) the first ctrl+z would undo only the auto-resize and the second ctrl+z would undo "create control". In the second scenario, the first ctrl+z would undo the automatic resize, keeping the pasted part selected and ready to be moved to the desired spot.

(A similar change could also help for other automatic operations (cluster size to fit, etc.))

For example, MS word has a similar mechanism for the auto-correct option, if I type "this adn that", it will turn into "this and that", but the auto-correction can be undone separately, at which point it is no longer applied in this text location.

[tst]

I think the main problem with this is that you will end up with a structure that has both auto-grow and hidden code. Presumably, since you still have auto-grow enabled, it will kick into play and resize the structure again as soon as you do another edit operation (such as clicking Shift+arrow to move the code which is now selected, since you undid the autogrow).

I think a better solution for this specific problem would be for the placement code to be more intelligent and give more importance to fitting the code into the containing structure than to placing it centered on where you clicked (which most people probably don't realize is the behavior anyway). I know that I'm not a perfect center-clicker and I occasionally have to go through the oh-I-dropped-about-40-pixels-to-the-left-now-I-need-to-undo-and-redrop-it-about-*there* procedure. LV should be smart enough to fix that mistake, at least, on its own.

The same thing should happen with Create Control.

[X.]

this thread comments on the same "Terminal placement" problem used as an illustration by Altenbach.

Since I am not an autogrow user (I am actually a fierce opponent of it because of the havoc it generally creates in even moderately complex diagrams), I'd say let NI fix editor problems before adding features aimed at patching them.

I would love seeing NI acknowledge this flaw of their diagram editor, BTW...

[AristosQueue (NI)]

> I would love seeing NI acknowledge this flaw of their diagram editor, BTW...

It's not a flaw. The feature of double undo was explicitly considered and rejected. I wasn't directly part of the discussion, but I believe the argument went something like this... It only makes sense to have a middle state -- as, for example, MS Word does for text substitution -- if both of the following are true:

a) the option to do the substitution is universally enabled (ie there is no ability to turn off autogrowing on a per structure basis)

b) two edits do not both trigger the same behavior (ie. typing some other word somewhere on the page now again triggers the same text replace... or, in LV's case, a second edit triggering the need to resize).

If either of these are false, then after the undo, the behaivor of the editor becomes poorly defined for further edits to that same structure node. You end up with a node that has AutoGrow clearly turned on in the popup menu but it clearly isn't autogrowing. This was felt to be a very strange situation. And if the first undo turned off AutoGrow, that was even stranger. Turning it into a tri-state setting of "on", "off" and "repressed temporarily" didn't seem to help matters.

If you'd like to propose details how you would make this viable, be my guest. This is one of those ideas that would require the community to flesh out all the fine grain details since the R&D team already looked into this and said, "Nope. Not viable."  But that doesn't mean we wouldn't *like* it to be viable, which is why the idea hasn't been declined.

[X.]

I was refering to the bad placement of terminals. I have no comment about the undies.. I mean undoes.