Type Definition inside Refnum is not (always) updated

[raphschru]

Hi, I found another type definition update bug.

When placing a type definition inside a reference data type, there are cases where it won't be updated after a change made to the type definition:

 - typedef inside a strictly-typed control refnum;

 - typedef inside any reference type inside class private data;

Here is an example where I read the value out of various reference types, either from class private data or from the refnum directly.

After renaming the type definition, coercion dots appeared where the update did not happen:

A type definition is expected to update every occurrence regardless of the level of nesting inside other types.

This bug forces to always recreate reference types from scratch when their internal data type is updated.

Tested with LV2016 and LV2022 (32-bit).

PS: the bug also applies to User Events and RT FIFOs…

[raphschru]

The bug was submitted to NI and has the CAR ID 2470231.

[raphschru]

Hi, coming back with some updates.

It seems a lot of these issues were corrected in LV2024 (possibly in relation to bug fix #221246).

Now, when the typedef's qualified name or data type are modified, the following refnum types (that contain the typedef) update correctly: Notifier, Queue, DVR, Network Stream, Shared Variable, RT FIFO, User Event.

But there are still refnum types that do not update correctly:

 - Strictly-Typed Control Refnum (in all cases);

 - Event Registration Refnum (when the contained typedef is renamed AND the event registration refnum is inside a class);

 - Strictly-Typed VI Refnum (in all cases).

Here are the same results illustrated as screenshots:

After renaming the enum typedef:

After changing an item's name in the enum typedef:

Attached is the code example updated with the issues remaining in LV2024, which were reproduced both with LV2024 Q3 (64bit) and LV2025 Q3 (64bit) on Windows 11.

Steps to reproduce:

1. Open the project with LV2024 or LV2025;

2. Open VI "MyClass.lvclass:Test - Remaining Issues in LV2024.vi", notice that the VI is not broken and has no coercion dot;

3. Rename "Type Definition.vi" to "Type Definitions 2.vi";

4. Notice the coercion dots appear in the VI;

5. Edit the items of the enum in "Type Definition.vi" (rename the first item to "test"), OK, File > Apply Changes;

6. Notice the broken wires in the VI.

Each time there was a coercion dot or a broken wire, the typedef'd data type inside the refnum did not properly update, as it should have.

Regards,

Raphaël.

[raphschru]

The mentioned remaining issues in LV2024 were filed to LabVIEW R&D as Bug #3595572.