A Callers recompile is NOT undone when the subVI's changes are undone

[danny_t]

Hello All

I suspect this is expected behavior and not a bug, but I will ask anyway.

Load a top level VI into memory and then open a subVI (a.vi) from somewhere within its hierarchy, also ensure a.vi's caller (b.vi) FP is open somewhere just so you can see the FP and the VI changed asterisk.

If you now do an edit to a.vi that will cause it, and it's caller, to need to be saved, for example delete  or rename a FP control, both VI's will show the VI change asterisk as expected.

Now on the subVI (a.vi) use Ctrl-Z to undo your change and as expected the VI change asterisk disappears and the VI can be closed without a save prompt. However any caller VI's still show the VI changed asterisk and will come up with the save prompt when you try to close them.

If you have a large project with lots of VI and you work by loading your top level, I think this can be a causes on quite a few unexpected changes to VI.

I just wondered if people would expect the "un-do" to be a little cleverer than it is ?

cheers 

Dannyt

[Ben]

I'm not sure if that is expected behaviour. i do nkow I can't undo beyond the most recent save. Do you have auto-save turned on (it on by default I think).

Ben

[altenbach]

It only happens if you mess with a control that is connected to the connector pane. Other changes in the subVI don't do anything to the caller.

If you look at the "changes" in the toplevel VI, is says a subVI call was modified. This makes sense, since the toplevel VI actually got broken while you had the control deleted, but you only did an undo in the subVI. It might be difficult to tell for the toplevel VI what you actually did to the subVI so it plays it on the safe side. I'm OK with that. 🙂

[tst]

Actually, this also happens if you do something that changes the inplaceness of data which has to do with the caller (e.g. using shift registers instead of tunnels, removing case structures).

[danny_t]

Hi

Thanks for your reply's

Ben ,  I  always have the auto-save turned off, for me it interferes with the source control system if I do not. I had not noticed that you cannot undo past a save, that is in my view a shortfall, MS Office and many other applications allow you to do this and unlike my original question, which I can sort of see as being hard, surly this would be an easy thing to do.

Yes I agree with you tst, anything that changes the inplaceness (is that really a word) of data, but I am interested if you think this a) expected b) good.

Altenback, I do understand your comment that it would be difficult for the top level VI to know what is going on down below and  in truth I do not think this behavior surprise me, but to me it is a pain. Using a source control system I really want to know, for review purposes if for no other reason, which actual VI's have been edited by

a programmer for a bug fix or feature change and I have always been unhappy about  the "unedited" VI that appear on this list, so anything that I can find to stop unexpected VI changes to me is a good thing.

It would be nice if one of the save options when you close a VI was to automatically "do not save, or prompt for save" VI who's only changes are a subVI has changed.  Then I could load top level change all the actual VI I need to edit, close all and only save those VI that have been edited each with a relevant comment into the source control system, then open the top level again and on closing this time save the changed VI all with the say "VI save due to subVI recompile" comment"

cheers

Dannyt

[tst]

Try Tools>>Options>>Environment>>Do Not Save Automatic Changes.

It disables the prompt for saving for changes like this (or typedef changes, etc.) and I believe is exactly what you want.

I don't use it myself, so I can't comment on how it works.

Incidentally, I fail to see what the auto-save has to do with SCC. The auto-save saves a temporary copy to the LabVIEW Data folder for recovery purposes. It does NOT overwrite your own files. It may indeed prevent undoing, although I don't remember running into that myself. I remember there was a discussion about it (probably in one of the betas), but I don't remember the results.