07-07-2014 05:22 AM
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
07-07-2014 06:44 AM
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
07-07-2014 09:31 AM
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
07-07-2014 09:54 AM
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
07-07-2014 09:59 AM
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?
07-07-2014 10:03 AM
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
07-07-2014 11:33 PM
07-08-2014 02:06 AM
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
07-08-2014 02:43 AM - edited 07-08-2014 02:45 AM
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!
07-08-2014 03:28 AM
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