LV 8.6.1 reports Bogus Error

[CoastalMaineBird]

LV 8.6.1f1

My VI has an error.

I click on the (broken) RUN button to find the error.

In addition to the error I expect, I find a bogus report (sometimes more than one).

The bogus error is always about an "undefined type", except it's bogus because the type IS defined (notice the wire to the CLUSTER CONTAINING MOUSE indicator is NOT broken).

The bogus error is always about a refnum control or indicator. 

If I fix the real error (enum conflict) the bogus error does not show up.

The enum has nothing to do with the indicator mentioned. 

Weird. 

  

[Broken_Arrow]

I've had this error as well (also on 861f1). It occured any time I edited an enum being used to select cases, and the code had to recompile (apply updates) to the cases. There would be an unrelated control that somehow lost datatype... but not really.

I have also had this error where I fix another issue, expecting the bogus issue to repair itself, but the arrow remains broken. But, I click the broken arrow and the VI runs  and then remains repaired (broken arrow is gone when I hit stop).

edit: maybe it just resents my username 

Message Edited by Broken Arrow on 08-16-2009 09:31 AM

[CoastalMaineBird]

maybe it just resents my username

Heh.  Maybe you should call yourself "Chief Running Bear" and it would work. 

[Andy_C.]

Hello Steve,

Could you post an example VI that demonstrate the error so I can validate it and report to the R&D.

Thanks!

[CoastalMaineBird]

Could you post an example VI that demonstrate the error

Wow, it turns out to be remarkably easy to demonstrate.

Attached is a VI.

Below is a picture of it.

The rule seems to be

IF

   a CONTROL/INDICATOR is a REFERENCE to a CLUSTER

AND 

   some other error exists on the VI

THEN

   complain about HIDDEN GIZMO has no type

ELSE

   don't complain. 

Just delete the bad wire and BOTH errors go away. 

 

[Andy_C.]

Hello Steve,

Thank you for the bug report. I've validated the same error occurs in LabVIEW 8.6 and 2009. This behavior is reported to R&D with corrective action report (CAR #183198) and hopefully we will address this issue in the near future.

Thank you