LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW changes enumeration constant values randomly


@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

 

 

 

 

Message 21 of 45
(825 Views)

@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

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 22 of 45
(809 Views)

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.

Message 23 of 45
(779 Views)

@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

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 24 of 45
(769 Views)

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.

 

______________________________________________________________________
0 Kudos
Message 25 of 45
(757 Views)

@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. 

 

0 Kudos
Message 26 of 45
(763 Views)

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.

Message 27 of 45
(763 Views)

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

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 28 of 45
(755 Views)

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!

0 Kudos
Message 29 of 45
(739 Views)

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

Message 30 of 45
(686 Views)