Potential Undo Bug related to Forced Recompilation of large VIs?

[X.]

I have stumbled upon a strange problem in my application: I would force recompile (Ctrl+Run Arrow) to solve some broken wire due to the lack of recompilation after a typedef change or some kind of replacement, and after a couple more actions, or right away, would decide to undo all that... to no avail!

In other words, even though I have set the number of Undo steps per VI to the maximum of 99, a few modifications (or even a single one) cannot be undone (the Undo menu item in Edit is grayed out).

Recently, I was trying to solve a basic problem (which I may discuss in another thread) by inserting a "Always Copy" primitive on a wire:

and forcing recompilation. Since it had no effect (did not solve my problem), I decided to remove it by a Ctrl-Z. Nothing happened. I tried a few times (my  wireless keyboard has had some hiccups in the past) and then checked the Edit menu, only to discover that the Undo item was grayed out (as was the Redo item).

Obviously, I checked on a new clean VI with almost nothing in it, and inserting a Always Copy primitive and forcing recompilation did not prevent an Undo.

My suspicion is therefore that this is a problem related to the size of the VI (a forced recompilation will take a dozen of seconds and will white out some of the diagram in that specific case). What I am not sure about is whether this is "expected", in the sense that forcing recompilation might involve a lot of "hidden steps" which, once crossing the 99 threshold are preventing any Undo, or whether that qualifies as a bug.

Needless to say, not being able to undo in a large VI can be problematic (not necessarily the step that preceded the recompilation, but say, the few steps before) if not downright catastrophic (if the recompilation resulted in lots more broken wires than originally.

Comments?

[mikeporter]

No, I would say this is not a bug. How would you go about undoing a compilation over which you have no control?

Why would a forced recompile result in any extra broken arrows? If it did result in more broken arrows, then I would say it did its job in finding things that were broken but for whatever reason wasn't getting flagged.

Worse case you could restore the previous version from your source code repository.

Mike...

[X.]

If you read carefully, I am discussing the case where there is NO broken wire, I add a Always Copy primitive (still no broken wire), recompile (no apparent changes to the VI) AND the undo stack is cleared.

I believe this is a MAJOR problem potentially (say I have 90 pending undos and they are all cleared up without warning).

The broken wire discussion is here to explain why you might be interested in forcing recompilation.

[X.]

And to further clarify: the VI/project I am talking about was loaded from disk after having been saved. In other words, there is in principle nothing to recompile. To make sure that was the case, I forced recompiling before saving the VI, closed the project, reopened the project, modified the VI (adding bends to some wires). Then:

1) forcing recompile after those basic steps did NOT prevent undo-ing all these wire bending steps.

2) inserting a "Always Copy" in one of the wire (doesn't matter which) and forcing recompile did clear the undo stack.

I am arguing that such a "recompile" action, which should result in absolutely no changes, should not clear the undo stack.

I would further argue that ANY recompile action should be undoable as a single step. This might be the topic of a feature request, arguably, but the point is that I cannot see anything in the documentation explaining (or warning against) what I described.

[natasftw]

---

@X. wrote:

And to further clarify: the VI/project I am talking about was loaded from disk after having been saved. In other words, there is in principle nothing to recompile.

---

Then why exactly are you recompiling?  That's a pretty strange use case.  "maintain undo options from a VI that hasn't been changed at all." 

Let's say this is a bug.  There's a pretty obvious workaround.  Don't force recompile when you don't have a need to do so.  Now, you've saved yourself a step AND your undo history.

[tst]

I have no direct comment on what the desired behavior is. Obviously, it's better to always have undo available, but I never looked closely at which things clear the undo cache and that includes force compilation.

What I will say is that if you have something that happens with your code and you can't reproduce it as a minimal test case, you should probably contact NI directly and give them your VI, so that they can see it too and tell you whether this is a bug or  by design.

[X.]

It's a 2000+ VIs project, so that's not really practical.

[tst]

Well, I do see NI occasionally say that they will take large hierarchies, so it's up to you to decide whether it's worth the hassle.