enum type def name change gives coercion dot + name text to integer

[RavensFan]

I see that the menu choice is called Review and Update.  Maybe it was Relink in older versions.

Anyway, when you do pick one of those greyed out constants, right click and pick "Review and Update from TypeDef".  It will bring up a dialog box showing some conflicts based on default values that no longer exist in the TypeDef.  Go ahead and pick a new default and Approve the changes.

Now all the coercion dots have gone away.  Go through your code and make sure all of your constants are set to the values you want them to be.

Remember if that you ever need to change the items in your typedef, you do it by opening the Typedef and making the changes there.

[Carmen92126]

A little progress. I finally found a greyed-out enum. And there it was, "Review and Update from Type Def". 

Selecting that option, up popped a box that had me approve changes. I approved them and the coercion dot disappeared. 

But this leads me to question, what is the proper way to change the name of an enum type def? 

Starting from the stock example, simple state machine.

I thought it worked like this:

1. Select any instance of an enum type def, right-click and select "open type def". (this example starts with one enum type def)

2. Right click on the control, and select "Edit Items"

3. Peform needed action like adding states or changing state names

4. Save and close type def control

5. All instances of the type def enum will automatically update if "Auto-Update from Type Def" is checked. (In the state machine example, all instances are set to Auto-Update from Type Def).

These are the five steps I followed, and the coercion dot appeared.  It seems that the problem was that some instances of the enum set to auto-update, didn't automatically update.  

[Carmen92126]

A little more progress. 

I learned which enum doesn't update. It's an instance (presumably any instance) that is set to (shows the name of) the state name that was changed. This enum is greyed-out. I have to select "Review and Update from Type Def". Then it works. 

All instances that were set to a different state (different than the one that was changed) were automatically updated.

Question:

Is this a bug in the "Auto Update from Type Def" feature? 

[crossrulz]

Yep, this review thing is definately new to LabVIEW 2014.  In the LabVIEW 2014 Update Notes, there is a passage about this.  In a nut shell, this feature allows you to verify the value of a type def instead of it just going back to the default value.

[RavensFan]

That explains why the word "Review" didn't sound right to me.  It seems like a good feature to have been added.  And it explains why Carmen was seeing different behavior with 2014 as compared to 2013.

[shree_bala]

Hi Folks,

When I connect normal enum to the typedef enum coercion dot occurs. I checked the .ctl, auto-update was enabled.

I have attached both .ctl and vi files. Could anyone help me out!

Thanks in advance.

Best regards,

Shree

[RavensFan]

There is always a coercion dot when mixing a typedef with a normal control.  They are different datatypes.  One is defined as a typedef.  The other is not, it is a normal control.

If you want to get rid of the coercion dot, then you need to use a typedef constant to connect to the typedef control.

One other thing.  It is usually better to have the enum be the typedef, not the array.  Instead of a typedef array of enums, you are better having an array of typedef enums.  It sounds like a subtle difference.  The enum is what is special with its various items and what needs to be typedef'ed.  The array is not special in and of itself and doesn't need to be typedefed.  The reason is that whenever you have an array of something, at some point in time, you are going to work with the individual elements of it.  You want those elements of the array to maintain their special definition rather than getting lost.