Bug discovered when typedef contains array of unlabeled objects

[MegaHertz]

Hi all,

I was grinding away on my current project last week when I realized I had started getting the dreaded "VI failed to compile" errors. After extensive hunting and tweaking etc (you've all been there), I tracked down the problem to this: I had a typedef block diagram constant that contained an array of unlabeled Objects.

It's just a quirk of mine, but I am compulsive about removing labels from my array elements to reduce context help clutter. Since the array is labeled, I don't want or need the element to also have its own label (until, apparently, now).

I discovered the issue in LV 2019 SP1, and had a colleague reproduce it in 2020. If you'd like to see for yourself:
-In a ctl file, create an array of LabVIEW Objects.
-Save the ctl, place it as a constant in a VI, and save. Everything's fine, right?
-Now, go back to the ctl and remove the object's label. Save the ctl, then save the VI; it will fail to compile.

The workaround here is simple enough (just keep the object labeled), but a bug is a bug. If LabVIEW can't handle this and must give a "typedef contains an array of unlabeled objects" error, that's fine, but the generic compile fail error isn't helping anyone.

Can y'all out there reproduce this, and if so, what is the best method of reporting bugs to NI these days?

[crossrulz]

I don't even see a reason to create that type def.  I understand arrays of type defs, but not type defs that are arrays.  Why?  Because you lose you type def as soon as you index the array in some way (autoindex on a loop or use Index Array).  So since you are already using objects, you already have the base control type defined and therefore no reason to create another type def that is just an array of a type def.

[MegaHertz]

I agree. What I have described is a deliberately simplified example for the purposes of demonstrating the bug.

In the actual use case where I found this, I have a typedef cluster that defines a given "Test Scenario" ("Name" string, "Description" string, "Actions" object array, and "Pass/Fail Criteria" object array). Really, it was a typedef cluster that contained the problematic arrays.

After deducing what was causing the problem, I confirmed that the bug is present whether or not the object array is contained in a cluster.

But yes, just making an array into a typedef is pointless 😀.

[billko]

It is considered bad LabVIEW practice to remove labels from objects because it leads to a confusing front panel, and especially the terminals on a block diagram.  Now there's one more reason - apparently you can confuse the compiler as well.

[raphschru]

I just lost a couple hours trying to narrow down this exact same issue, definitely a bug!

I also usually remove the element's label from all my arrays because I find it redundant with the name of the array itself, and I want to keep the context help of the data types as light as possible. Reproduced with LV2016-32bit, LV2021-32bit and LV2023-64bit.

 @MegaHertz

Have you by any chance reported this to NI?

Regards,

Raphaël.