Enumeration conflict after updating typedef

[BrotherTom]

Hi everybody

I'm facing a problem that only occurs with one specific typedef enum in my application. This enum contains something more than 80 elements and as my applications grows I need to change this one from time to time naturally.

So in case of a change I open the typedef, do the changes (remove/add/rename items) and close it again with saving the changes.

Now what (not always but often) happens is: Many instances (constants) of the typedef lose their value as it is set to the first enum value (0). The broken wire appears due to an enumeration conflict occurs (see attached screenshot). It is extremely annoying to update all of these instances manually, and it's not the actual purpose of a typedef indeed.

Any of you faced this problem too? No idea why this happens with this one typedef control and never with any other in my application.

Many thanks for your help!

Thomas

[aputman]

Do you reorder the controls in this typedef?

[crossrulz]

---

BrotherTom wrote: do the changes (remove/add/rename items) and close it again with saving the changes.

---

The removing items and adding items in the middle of the enum will cause many of the values (the ones after the change) to reset to the default.

The broken wire looks like a bug to me.  I would recommend trying to open up a support ticket with NI to see if they can hunt that one down.

[Bob_Schor]

I think LabVIEW does its "best guess" to keep things "stable".  For example, if you had a Color Enum with Red, Orange, Yellow, Green, and Blue and added Indigo at the end, there should be no problems other than a possibly "broken wire" for a Case selector.  Recall that LabVIEW assigns R, O, Y, G, B to the numbers 0 .. 4, so adding Indigo as 5 causes no confusion.  But what if you remove Orange?  Now Yellow becomes 1, not 2, and so on.  Many times LabVIEW still gets it right, but if you now start rearranging the items in the Enum, it can get tricky.

Something I use to find problems is to first load all of the VIs where the Enums are used into memory.  I then open the Enum's TypeDef and do a Find All Instances, which brings me to the places that the Enum is used.  I can then look for possible "wrong assignments" and fix them.

Bob Schor

[Bob_Schor]

The broken wire in your example is probably because the cluster MAC - AdrCheck didn't get the updated Enum definition (or, if it did, the constant you are feeding into it still has the old definition).

BS

[Ben]

BrotherTom

Updating type-defined Enums have always been a challenge due to the many situations the previous answers have indicated.

In "the old days" a Tree.vi (or catalog if you are Mac user) was used to hold all top level VIs and force a load of all VI including those loaded dynamically. THe method at that time was to only edit the enum when the tree was opened.

After the introduction of the Project and shortly thereafter LVOOP the methodology shared by Stephen Mercer was to edit the enum with nothing open and THEN open the VIs using it. If I recall correctly this was due to LV having some extra logic that was invoked when a VI was opened and found the enum had changed.

More recently LV introduced a dialog window that helps us resolve the enum conflicts and fix them.

Which of the above approach works best for you is something I would like to hear back from you as you try them out.

But returning the challenge of editing and re-arranging enums...

There was an old-school philosophy of software development that said we should never delete code only comment it out.

In the case of enums, I apply this rule of thumb by avoiding removing enum items if at all possible. Just keep adding to the collection... if you can.

So if I am now faced with removing a enum value and/or changing a value, I avoid testing out the "can LV read my mind?" option and make the changes as explicitly as I possibly can. This means I deal will each change one at a time, apply Alll (drop down in control editor) after every change. Mixing all of the changes into one update of the enum is asking for trouble. LV may be able to handle it, but I have wonder off into enough dark corners of LV to know that while LV is exceptional at reading my mind, sometimes we will find use cases that NI never considered.

Just my 2 cents,

Ben

[BrotherTom]

Many thanks for all answers! I tried to add an element at the end of the enum... everything worked fine. Adding or deleting a single element sometimes works fine also, not everytime. But it doesn't depend on reordering or not reordering some elements.

I got used to LabVIEW to be able to assign the elements correctly after editing the typedef when elements keep their names, even though some other items have been removed/added. And in case LabVIEW won't be able to find one element anymore, I already got used to the "Review and Update from Type Def" dialog which I consider as a great tool.

In order to have a logical order inside the enum I often add the elements between others, and not always at the end. When you deal with more than 80 elements it is cumbersome to have a messed-up enum. In my opinion...

What comes to my mind regarding this topic is the following: Many of my Classes, VIs, etc. are included in a lvlib. When I duplicate this lvlib to extend my application I see that coersion dots arose in the new lvlib when using the new classes:

These were not there in the original lvlib. Behind this property there's an class data accessor VI that contains the same type def as the constant shown in the screenshot. So why the coersion? Solution: I select a property other than "Thread" and then select "Thread" again... The coersion dot will be gone.

This example shows me (jumping back to the original issue) that the interface through a property node can be erroneous even though the VI behind contains exactly the same data type. This explains why such a case...

... can occur when editing an enum: Because after saving the changes these might not have been applied to the interface yet.

[BrotherTom]

Hi again

I'd like to defrost this one again since I have NO IDEA what to do to solve it.

I started adding new elements at the end of the enum, but many of the instances get resettet to the zero value. Only difference: Without the broken wire... which makes the erroneous instances even harder to discover in the depths of the code. It's driving me nuts!!

Isn't there anyone out there who has the same problem?? I can't imagine at all that I'm the pioneer! How can this be conquered???

By the way, Ben: Sorry for not replying to your detailed post! But unfortunately your proposals did not work. And I agree with your opinion that we should make things easy for LabVIEW to handle. So I make one change at a time. This is how I always do it.

The only "solution" I can imagine for myself: It must be a bug.

[Ben]

If you followed our suggestions and are still having trouble then...

Get anal-retentive about backups before any enum changes.

take notes on what you do in what order

When things go sideways stop, go back the the backup and repeat your steps.

If you can repeat the issue BINGO you may be a candidate to win a shinny new CAR (correct Action Report).

Call NI, log a service request and send them a copy of your backup and the instructionto recreate the problem.

If the Appl. engineers can re-create the problem they will first try you find a work-around. This is where logging a service request could pay-off for you. They may be able to tell you howmany times to swing th cat before tossing the salt over your shoulder and editing the enum.

I have been sharing code with NI for bug purposes for years and they will keep the code secret and safe and will delte it as soon as they can unles they need it to reproduce the bug.

While I suspect you would rather have someone post the work-around to this message, sometimes small changes in how you are doing things can make all of the difference. Example: There is at least one bug active now that only happens if a developer is not using the auto-tool seletion option. Tht bug would haunt me but many newere developers will never see teh issue.

Doing what little I can to help you,

Ben

[JÞB]

The one thing you have not provided:

Version of LabVIEW?  2014 had some upgrades to typedef constants.   yes, typedef constant values have been problematic but, getting smarter! or - can you provide a case where they got worse?  (Smarter is never "Allways better")