Enumeration conflict after updating typedef

[BrotherTom · Accepted solution]

Hi

I was out of office for 2 days. Thanks for replying, and sorry for placing my upset here!

Ben: Your post triggered an idea in my mind... So I opened the typedef and edited it. Without applying the changes I saved only the typedef and closed the whole project. After reopening it everything was fine! Of course except the edited element which was grayed out waiting for me to call the "review and update" function. So the problem has not gone but this workaround is acceptable for the moment.

However I called NI for a service request, in case it's a bug.

Many thanks again!

[Ben]

"So I opened the typedef and edited it. Without applying the changes I saved only the typedef and closed the whole project. After reopening it everything was fine! "

That is similar to what I mentioned was the recomendation from Aristos Queues that takes advantage of "extra" logic that is invoked to resolve typedef changes when a VI is OPENED.

If you get to a point where you can duplicate the bug, please do follow through with support.

If you go a while "knowing how many times to swing the cat" and do NOT have trouble, it will help all of us if you could update this thread to lett us know what is working for you.

Hoping you have found the trick,

Ben

[Hooovahh]

---

@JÞB wrote:

Version of LabVIEW?  2014 had some upgrades to typedef constants.  

---

Oh yes, I've been using this extensivly the last few days and I'm a big fan.  I have some scripting code that goes and generates all the possible values of an enum, adding or removing items from an existing enum.  This existing enum has code that calls it, and updating the enum is fine, but as soon as you open the old code that calls a different value it has it greyed out with a broken wire.  Right clicking allows you to review every time the value wasn't what it expected.  

[BrotherTom]

Hi folks

My service request at NI yielded the following (if I got them right):

There's a LabVIEW bug: If an enum typedef is part of a class and is used as individual instance (such as my constants), it might not be updated automatically and the case then ends up in an enumeration conflict. They told me to delete the enum constants and reinsert them with drag-and-drop from the project explorer because this is described as a possible workaround. Unfortunately this didn't work in my application.

Second option would be to create a second enum typedef which is not part of the class but contains exactly the same elements as the first one. Changes would then be necessary on both of the enums in equal measure. I will not implement this option because it's in a roundabout way and absolutely not WYSIWYG.

So I will continue working as declared in the marked solution until this one is fixed. Moreover this practice will be registered in the NI records as another possible workaround.

Many thanks for your help!!

[crossrulz]

Did you get a CAR# out of the NI support?  This is something a lot of us would probably want to watch for in the fixed bug list that NI puts out with a new release.

[BrotherTom]

Hi crossrulz

The CAR# is 352760.

Regards

[MrJackHamilton]

I am seeing this problem more in LV 2014 & 2013 then in past versions. It used to be quite robust when updating the TypeDef. Hence, My love affiar with them many years ago.

Workarounds: 

1. Opening the typedef and adding *something* sometimes kicks LV in the butt to notice the change - and instigate the TypeDef updates globally.

2. Starting to replace the typedef's by right-clicking and selecting 'replace'....will after about the 3rd one - kick LV to globally update.

I also notice, LV drops the Typedef off the enums..I ALWAYS create typedef for Enum's for state machine, right off the bat. I will occasionally see when the update problem ocurs - SOME of the early enums are NOT attached to the Typedef anymore - AND/BUT =- they show the newly added elements....this is an indication of a bug for sure.

Good luck

Jack Hamilton