LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Mysterious unsaved changes in project: Class type definition stored in member VI?

Hi,

 

I'm wondering: why does LabVIEW show changes in a member VIs of a class when I only change the type definition (cluster) of the class in way that the member VI has nothing to do with the changes?

 

Example:

 

Class A{

  int a;

  int b; //new! -> changes in A.lvclass and A.ctl

  incr(){ this.a++;} //why incr.vi needs to be updated/saved upon adding b?

}

 

Strangely enough, when I don't save the changes and close the project, everything looks fine after re-opening the project (no broken VIs etc.), but the issue with the unsaved changes remains.

 

The thing is that I don't want to upload "fake" changes into our configuration management system as my colleagues would think that I really did changes to the VIs.

 

Thanks!

 

Peter

0 Kudos
Message 1 of 19
(3,381 Views)

Peter,

 

you haven't configured the VI to "separate compiled code from source file". Is that correct?

 

You are running into the issue that changes to the class (cluster) forces the VI to recompile, even if neither FP nor BD are being changed. As without above mentioned option the compiled code is part of the VI file, the file has a "dirty dot".

If you don't save the file, re-open it, the compiler 'sees' the change of the class (cluster) compared to the compiled code and recompiles (so same story as above).

Note that the VI is not executable in a strict runtime environment if you do not save this change. Also note that this use-case requires you to have the compiled code in the VI file, so you cannot "work around", but have to save all methods of your class once you change the content of your class private data.

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 2 of 19
(3,365 Views)

Hi Norbert,

 

nope, source and compiled code are separated for the VI.

 

The reason why LV wants to save the VI is because "type definition has been modified" (translated from German LV). It's for almost all member VIs of the class, getter/setter methods, etc.

 

Any ideas how to prevent LV from touching these files?

 

Peter

 

 

0 Kudos
Message 3 of 19
(3,353 Views)

Peter,

 

do the VIs show a broken run error in this situation?

If so, saving the lvclass-file only should solve your issue (for separate compiled code!).

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 4 of 19
(3,347 Views)

No, they are all right (no broken arrow).

 

Do you think it's possible that class' cluster information is also stored in the member VI files?

0 Kudos
Message 5 of 19
(3,345 Views)

Peter,

 

can you provide a small example?

I am little confused as you write about type definitions, but i wouldn't call private data of a class a "type definition". The class itself is the type....

 

What version of LV are you using?

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 6 of 19
(3,341 Views)
There is an option to prevent LV from requesting you to save so-called automatic changes. Automatic chnages include things like recompiling from a previous version or changes in a type definition.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 7 of 19
(3,330 Views)

Norbert: I tried to reproduce it on a small project but I couldn't. Everything as expected. So unfortunately I can't send you an example, and the thing is becoming even more mysterious for me. I run LV 2012 without SP. It seems to me fully random which files need saving upon which change. The message says "type definition modified" without further information. Just opening the project makes the project file change (which is not the case in my small example project I was going to prepare for you). Then I change one cluster of a class (adding a fake attribute, nothing more), and my project sees dozens of unsaved changes (VIs of this class and in other classes). The source and compiled code separation option is set everywhere.

 

Here is a topic that seems to be related aund unresolved: http://lavag.org/topic/17162-type-def-automatic-changes-not-being-saved-in-lv2013/

 

Mike: it may be a good hint but I don't know which option do you mean exactly. Can you be more specific?

 

Thanks,

 

Peter

0 Kudos
Message 8 of 19
(3,314 Views)

Peter,

 

it seems to me that the issue is connected to association or containment. Did you incorporate that in your small example?

Does it happen if you previously mass compile the VIs before you add the dummy item to the class' private data?

 

Currently, it seems more like a bug if indeed all items have "separate compiled code" set (e.g. in the project).

Is it possible that some single items have that option disabled? Remember: Setting the option in the LV options or the project properties, it refers to NEW items. Existing items are not changed by that "global" settings.

 

Norbert

 

EDIT: You can write a small tool to check this. Make the project path the input parameter, use VI Server to load that project and load all items and query the "separate compiled code" option. If an item has the option disabled, you might want to extend the tool to change the setting and save that item. Remember that the setting is available for more than 'only' VI-files!

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 9 of 19
(3,300 Views)

Hi Norbert,

 

I have association between classes in terms of data references but I don't know if it's what you mean. I added data references to my small example but I still can't reproduce the behaviour.

 

I tried to mass compile but I can still see the changes. By the way, what is mass compile good for?

 

Good that you point out the difference between the project and VI setting wrt code/binary separation. All VIs that are reported to have changed (without actual change) are set to separate code and binary.

 

Peter

0 Kudos
Message 10 of 19
(3,289 Views)