Typdef property node bug when converting from non-strict to strict

[ChrisStrykesAgain]

I had a typdef'd tab control that I turned in to a strict-typdef and suddenly I got coercion dots everywhere I used a property node (both implicit and explicit). That was annoying cosmetically, but I considered it a minor issue. Then I added a tab to my control and suddenly all of my property nodes caused broken wires; it appears the property node is not actually linked to the typedef.

Fortunately I only had a handful of property nodes, so this wasn't a huge deal for me, but figured I'd post here for public information/additional insight. I do have an open support request and will update with a CAR number when it becomes available. I discovered it using LabVIEW 2017 SP1 f4, but it reproduces in 2019 f0; haven't looked to see if there are any patches available yet.

For those curious, to reproduce it using the attached code:

1. Open the VI; observe there are no coercion dots.

2. Open the typedef. Change it to strict and apply changes. Observe coercion dots.

3. Add a tab to the typdef. Apply changes. Observe broken wires.

I believe this also reproduces vice-versa (going from strict to non-strict), but haven't fully tested that path.

[ChrisStrykesAgain]

Update:

IFF you break the wire by changing the altered typedef, saving or force recompiling both resolve the issue (broken wire AND coercion dot), at least with a tab control. Just saving/force recompiling does NOT fix the coercion dot if the wire isn't broken.

[Ben]

If I read you correctly, you are talking about a tab control that is a type def.

I gave up trying to type def tab controls back in LV 7.1 figuring that that was not supported since they never updated and I had manually update any refs to tab control it they changed.

So this is news to me!

Ben

[ChrisStrykesAgain]

The case I attached is with a tab control, but the issue seems to reproduce with ANY typedef, from what I can tell.

[ChrisStrykesAgain]

Update: Apparently this is expected behavior that I've somehow never noticed before.

According to support, the propagation only occurs when a structural change is made to the typedef, thus coercion dots until that occurs. From what I can tell, the propagation still doesn't occur automatically, thus broken wires all over the place until you manually force it to propagate by hitting the run arrow or saving.

[Ben]

I have muscle memory that goes...

Apply Changes

Save All

(lather rinse repeat if it is a nested type def)

Then closing the type all is OK.

Side Note:

Switching from a type def to a strict and doing the above dance

AND THEN

Switching back to a normal type (again with the muscle memory dance) allows me to force all to look the same but still have to option to hide-show that an normal type def allows.

For what it is worth...

Ben