Strict typedefs changes value throughout project

[s.h._tech]

Hello everyone,

I have a StrictTypedef with an Enum and a String. The Enum holds the names of my Statemachines and the String holds various properties.

I added another Enum for Cases and I recognized that most of the Typedefs I used reverted back to their default settings throughout the whole project (>200 Vi). Luckily I saved the project before and can compare the instances.

Is there a way to 'fix' the values of an element which is not touched, even if I change the cluster (add some controls)?

[aeastet · Accepted solution]

No that is one problem with using these. NI does a really poor job maintaining integrity when a change is made to type defs. You have to be very careful when using these.

[s.h._tech]

I was afraid of that.

You learn something weird every day when using LV 😉

[paul_cardinale]

---

@s.h._tech wrote:

Hello everyone,

I have a StrictTypedef with an Enum and a String. The Enum holds the names of my Statemachines and the String holds various properties.

I added another Enum for Cases and I recognized that most of the Typedefs I used reverted back to their default settings throughout the whole project (>200 Vi). Luckily I saved the project before and can compare the instances.

Is there a way to 'fix' the values of an element which is not touched, even if I change the cluster (add some controls)?

---

I haven't had that problem.  And I just ran a quick experiment: when I added an enum to the typedef and applied changes, the existing instances retained their values.

[aeastet]

OK now try deleting one and see what happens.

[paul_cardinale]

---

@aeastet wrote:

OK now try deleting one and see what happens.

---

I did that too.  The values were retained.

[crossrulz]

What version are you using?  This was supposed to have been resolved a few years ago.

[billko]

My general rule of thumb is, when adding or deleting items from a typedef enum, always do so from the bottom of the pile.  If you're adding something, add it to the bottom.  Apply the changes and save all the cascading changes that it creates.  Then re-open the typedef and move the item on the bottom wherever it needs to go.

When deleting an item, do it in reverse - move the item to be deleted to the bottom of the pile.  Apply the changes and save everything that changed.  Then re-open the typedef, delete the item, apply and save all the changes.

The goal here is not to disturb the values of existing items when you add or remove an item.  LabVIEW is good at tracking order changes, and it's good at keeping track of added or deleted items - just not at the same time!

[billko]

---

@crossrulz wrote:

What version are you using?  This was supposed to have been resolved a few years ago.

---

Wasn't the "resolution" to alert you that it couldn't update the typedef default value and go to each instance so you can fix it yourself?

[s.h._tech]

Version: Labview 17

Sometimes I get the window, where I can compare changes. But this does not happen all the time.

I do not know what conditions triggers the 'change window'.