Save As and case structure changed

[ncm]

Has anyone come across this?  i did a 'save as' on a project that was working correctly, without changing anything except saving as a different name there were 2 out of 50 or more true/false case structures that reversed the cases.  This was fun to trouble shoot... has anyone seen this bug and is there a different way to avoid this?

[Bob_Schor]

I'm not sure I understand what you did.  What, specifically, did you save?  Was it a Project (which might save a bunch of internal VIs), a VI, or a Control/TypeDef?  Were the 2-out-of-50 Case structures in a single VI, or scattered in multiple VIs?  Were they simple Boolean Case statements?  Can you provide an example (inside the VI where the change happened) of code where the Case did a spontaneous "Make This (true) Case False" (or "Make This (false) Case True")?

It seems likely (but I confess to not know how) that you "did something" to cause this behavior ...

Bob Schor

[ncm]

I have one vi that is in a project, both the vi and project were saved with a different name using 'Save As'. The other 2 out of 50 are scattered in the one vi. They were simple Boolean cases. If this happened only once I would have just taken it as I messed it up. But I recopied the original file to do restart where I left off and did another save as but a different name, the two cases again were switched but not in the original file. I have been finding weird things since we upgraded a month ago to 2015 from 2010, this particular case the old file was 2015 but the file before that was a 2010, wondering if I have residual issues with the upgrade? I even double checked the original code and the case structure is correct, just in case the original file was switched without my knowledge... I attached a copy of the case structure that flipped. The Pass/Fail should be in the False case not the True Case What is also strange is I have 2 other similar program I have completed concurrently and had no issues with those programs and I saved the programs in the exact same manner and have had no problems. This was a new one for me.

[ncm]

Here is the attachment

[Bob_Schor · Accepted solution]

Ouch!  Are you using a lot of Local Variables, particularly inside loops?  Whatever is going on with your code, it is a function of the entire VI, so showing us such a tiny piece will not help much to find the "mistake".

What may be happening, particularly if you have lots of loops, lots of cases, and lots of Local Variables, is that some "meta-processing" of your code may have taken place, perhaps involving the inherent Race Conditions associated with Local Variables.

If you attach your entire VI, and if it has a "problematic" structure, I'm sure one of us will suggest how to clean it up, which may well make the problem "go away".

Bob Schor

[altenbach]

---

@ncm wrote:

Here is the attachment

---

That does not really tell us anything. In particular, if the case is TRUE. the indicator just retains its original value, whatever that was. Whas this before or after "saving as"? Since you saved uner a new name, can you attach both before and after VIs?

There has to be more to all of this. Can you show us a little bit more code?
I tried a "save as" and nothing changed....

[ncm]

I wish I could show all my code but can't because it is proprietary, I know that makes it impossible to help to diagnose. I wouldn't doubt it has issue with the mega processing, it is hand-me-down code I am working on and trying to clean up and update. I appreciate the two of you trying to help!! Thank you 🙂

[altenbach]

So, did the visible case change or did the case gets swapped (true case is now false, etc.) .

I am with Bob that most likely a recompile cause a slight change in execution order, exposing an existing race condtion.

[ncm]

The cases were swapped, what was inside the true was swapped with what was inside the false case. Again, thank you two, I will work on re-writing the code to avoid these hiccups in the future. Your time is much appreciated!