LVOOP Compiler bug with property nodes?

[John Lokanis]

I have seen a strange bug crop up when editing a large LVOOP project that uses property nodes in several classes.  When I am wiring into a class property node, the compiler does not complain about mismatched types all the time.  It sometimes just lets me wire anything together but later will report the VI as corrupt.

I first noticed this when accidentally wiring a scalar into an array (of the same scaler type) input on a class property node.  But just today, I had an instance where it let me wire a string to a numeric input.  (see image).

 

 

Is this a known bug?  Has anyone else seen this before?  Anything I can do to mitigate it?

 

I am using version 13.0.1f2

 

thanks,

 

-John

[justingruenberg]

I've seen this.  This has also happened to me when I've deleted a property of a class and LabVIEW takes a guess at what it should replace it with.  I don't have any real advise for how to mitigate it, but if you can at least track down where it is... deleting the node and inserting it again seems to fix it.

 

I'm almost tempted to give up on using property nodes.  I had an issue a while back where some property nodes would just take down LabVIEW or the built executable they were in.  There wasn't any complicated code behind them (most of the time this occurred, they were auto generated with the wizard).  At least now it's only corrupting VIs instead of taking down executables.

[John Lokanis]

Thanks for the reply.

Unfortunately, I cannot give up on them because I have a lot of data-only classes that I need to access the elements from methods in many classes (although that could be worked around with a lot of sub-vis) but I also have several DVR wrapped classes that I use property nodes to access the data.  So, I hope these gets fixed soon.

[smithd]

I remember this being an issue in 2011, but hadn't encountered it for a while. I recently ran into it again where the property node won't notice the transition from 1d->2d array. This may be fixed in sp1 patch f3 (look at issue 467722): http://digital.ni.com/public.nsf/allkb/4415B312CC61449A86257C820053B65E

 

If updating to this patch doesn't fix it, I would highly recommend letting the applications engineers know, and file a bug report.