LabVIEW changes enumeration constant values randomly

[dlanger]

---

@Ben wrote:

---

 

Please post the SR number and I will see if I can get this escalated. 

---

Thank you, Ben. The reference number of my support request is:

Reference#5033-PLB818

[Ben]

---

@dlanger wrote:

---

@Ben wrote:

---

 

Please post the SR number and I will see if I can get this escalated. 

---

Thank you, Ben. The reference number of my support request is:

Reference#5033-PLB818

---

Thank you!

I have notified support and asked for an update and CAR.

Ben

[Harlequinade]

Here's an interresting addendum...

We just found out that we are having a similar problem with class private data bundling/unbundling. We observed the bug only for one specific class. Using the procedure described above for the enum type-defed constants (steps 1-8), we observed that after dynamic class loading the order of the items in "unbundle by name" or "bundle by name" is shifted (often by one or two items). This of course corrupts the whole code. Again, "static" loading of the class in a own project leaves the code unaffected (i.e., either unharmed or in the already corrupted state).

Just like with the enum bug, either clearing the compiled object cache or re-fetching the relevant files from the Subversion repository restores the code.

The strange behaviour we already have been observing for a while, but just today we realised its correlation to the enum problem.

[Ben]

---

@Harlequinade wrote:

Here's an interresting addendum...

We just found out that we are having a similar problem with class private data bundling/unbundling. We observed the bug only for one specific class. Using the procedure described above for the enum type-defed constants (steps 1-8), we observed that after dynamic class loading the order of the items in "unbundle by name" or "bundle by name" is shifted (often by one or two items). This of course corrupts the whole code. Again, "static" loading of the class in a own project leaves the code unaffected (i.e., either unharmed or in the already corrupted state).

Just like with the enum bug, either clearing the compiled object cache or re-fetching the relevant files from the Subversion repository restores the code.

The strange behaviour we already have been observing for a while, but just today we realised its correlation to the enum problem.

---

When we get support to chime in it would be good if you could provide an example to help them reproduce the failure. It does not have to be posted in the public domain. BUt passing it to support will help our cause.

If you can't I understand.

Thank you!

Ben

[Ray.R]

Reading this thread is scaring me from taking a project from LV 2010 to LV2011..

I did attempt it and it was ... well...  maybe I should not talk about it..  😞

I think I will stick with LV2010 on this one.

I know I have an upcoming client which will use LV2011, but I do not yet know if LVOOP will be involved.

Thanks for posting all this information.

[Harlequinade]

---

@Ray.R wrote:

Reading this thread is scaring me from taking a project from LV 2010 to LV2011..

I did attempt it and it was ... well...  maybe I should not talk about it..  😞

I think I will stick with LV2010 on this one.

I know I have an upcoming client which will use LV2011, but I do not yet know if LVOOP will be involved.

Thanks for posting all this information.

---

I'm sorry we didn't give enough information in the first post, but we use LV 2010 SP1 32-bit on a Windows 7 64-bit machine and the LVOOP. 

[Drew_H]

Hey everybody,

I just wanted to let you know that we are looking into this, and because an SR has been generated we're going to approach it through those support channels. That being said, we understand that this has raised concerns for a number of you, and if any important information or developments arise (e.g., CARs being filed or additional workarounds), we will post those to this thread. I've been in contact with the engineer working on this issue, and I can assure you that progress will be made.

[Ben]

Hi Drew,

Thanks very much for taking ownership of this issue.

For that that are able and willing, how would you like them to share their demo code with you?

If it makes it easier the SR# I loged was

1786251

Again thatnks!

Ben

[Drew_H]

Hi Ben,

I'm under the impression that Harlequinade and dlanger are working on this together, and the engineer working on their service request should be contacting whoever's listed on the SR as the contact so we'll have access to their code via that method. However, if anyone else has any simplified code that might help us reproduce this specific issue on our end, posting it in this thread would be appreciated. Thank you!

[Roy_F]

Our immediate need is for code and steps to reproduce. If someone can provide these, either through this thread or offline for confidentiality reasons, I am very confident we can determine what is happening, why and how to avoid. We'll try to reproduce from scracth right now, but I am not optimistic we will be successful without specific steps or code.

Thanks,

Roy Faltesek

Senior Group Manager

LabVIEW R&D, Sustaining