LV Compiler doesn't know to run

[CoastalMaineBird]

LV 8.6.1f1 - Windows Vista 

Here's another instance where the compiler isn't being triggered properly.

I added a new value to a typedef'ed ENUM.

Things didn't work as expected, so I chased it to this piece of code:

 

The problem was, that I had not entered a case for the new type, but the "Default" case handled it.

That's my coding error.

So I said, "Well, this shouldn't have a default handler, I need a case for every value", so I removed the DEFAULT designation:

 

Hmmm, I said.  Shouldn't that be an error?  The TYPE variable is the typdef'ed ENUM that I just changed.  There is no case to handle it. That has to be an error.  But no.

However, if you click the RUN button, or SAVE the VI (or probably other things), the compiler runs and properly complains:

 

It's not a big deal; it cannot stay in that state for long, since saving cures it.  Trying to run the parent VI changes it to broken.

It works the other way, too:  If you take the broken VI and MAKE THIS THE DEFAULT CASE, you've cured the problem, but the VI is still broken.  If you click on the broken arrow, it compiles, and un-breaks the arrow.

Weird.  Somehow the compiler should be reacting to the change, but isn't. 

[David_L]

Hi Steve,

Are you able to see this from other VIs or just this one?  I tried replicating this problem by creating a type def enum connected to a case structure.   No matter what I tried doing I could not replicate the behavior you are seeing.  I tried:

1. Adding a value to the enum while there was no default case.

2. Adding a value to the enum and then removing the default case.  

Please let me know if I am missing something in the steps to reproduce this.

[CoastalMaineBird]

This one is easy to reproduce. Perhaps it's related to the typedef'ed ENUM being contained inside another TYPEDEF, and perhaps that's the part you didn't replicate.

In any case, here is an extremely simple test VI, that will show the problem.

Open the CompilerBug.VI, and follow instructions on the diagram.

[David_L]

The good news is I was able to replicate the problem on my end in LabVIEW 8.6.1f1.  The Better news is that this was already fixed in LabVIEW 2009!  The bug doesn't seem to be documented anywhere so it must have been accidentally fixed.  I will report this to R&D so hopefully it doesn't go back to not working in future versions, but this should not be a problem with the most current version of LabVIEW.

Cheers!

[CoastalMaineBird]

it must have been accidentally fixed.

I can't tell you how comfortable that makes me feel...