Odd compilation behaviour

[LAVA 1.0 Content]

I've a LabVOOP 8.20 project with very odd behaviour. When I open the project and close it immediately LV claims that the project has unsaved changes. When I use "Explain Changes" to view the changes, they are following:

For three static method VIs belonging to three different classes (root, childA & childB) the changes are

• VI recompiled.
  
• SubVI call(s) modified.
  

For two classes (root & childA) the changes are following

• Name or location of items in the file system changed.
  
• The private data control for this class changed.
  

If I then select Save all, LabVIEW still claims that one of the classes (childA) still has unsaved changes and asks me to save the class.

Both the root clas and childA class have an array of objects in their private data cluster. Root refers to an array classes in another hierarchy and childA refers to an array of class root to allow tree structure. There is a third class baybyC which also has an array of root as private data but the problems seem no the be related to that class; however I do not yet use that class in any of the VIs.

When I open the project and press Save All, LV saves five files. When I press Save all again, LabVIEW saves one file. When I press save all third time, LV doesn't save any more files.

My project has 154 files including 1 lvlib library, 4 typedefs, 4 polymorphic VI encapsulating static class methods, 18 classes, 126 class methods inlcuding static, dynamic and override methods and 1 top level VI. Everything else except the top-level VI are part of one of the classes in the class hierarchy. Everything belongs to a single lvlib library mentioned above.

When I open the top-level VI and press ctrl+shift+run, LabVIEW compiles all the VIs (?). If I then press Save All, LabVIEW saves 151 files. When I press Save all again, LV saves 3 more files. When I press save all the third time, LV has nothing to save. If I close the project now and reopen it, LV has again unsaved changes as described above. If I manually open each and every VI front panel and then press ctrl+shift+click on the top level VI, the behaviour is exactly the same, i.e., the odd behaviour is not due caused by the fact that there would be some VIs that were not in memory.

I thought the odd behaviour would be caused by calling class methods using call-by-reference node. So I removed this and replaced it with stack recursion, but the odd behaviour still remained. Any clues what could cause this odd behaviour? Is LabVIEW functioning as expected or is there something weird in the behaviour as I expect. This same project has shown corruptive behaviour, I don't know if this corruptive behaviour and crashing is related to this same odd behaviour or something else.

As a conclusion I expect this odd behaviour to be related to using tree structure in classes root and childA so that childA refers to an array of root class in its private data cluster. When I compile all, the compilation process probably doesn't understand this recursive structure and therefore compilation isn't complete even after pressing Ctrl+Shift+Run.

[crelf]

When I open the top-level VI and press ctrl+shift+run, LabVIEW compiles all the VIs (?). If I then press Save All, LabVIEW saves 151 files. When I press Save all again, LV saves 3 more files.

Your verbiage may actually be the key here - you say it "saves 3 more files" and not "3 more VIs" - what are the files? Is LabVIEW saving some kind of history? Is the project itself one of those files? Is it one of the support files (eg: aliases)?

[LAVA 1.0 Content]

Your verbiage may actually be the key here - you say it "saves 3 more files" and not "3 more VIs" - what are the files? Is LabVIEW saving some kind of history? Is the project itself one of those files? Is it one of the support files (eg: aliases)?

These three files are three of the classes i.e. .lvclass files. These three files are among those 151 files already saved previously, so I wasn't exact enough in my sentence. Also two files from vi.lib belong to these 151 files. I assume the unsaved ones are the 4 polymorphic VIs. 151 saved files + 4 unsaved polymorphic + 1 unsaved lvlib -> 154 files in project + 2 files in vi.lib.

[Aristos Queue]

These three files are three of the classes i.e. .lvclass files. These three files are among those 151 files already saved previously, so I wasn't exact enough in my sentence. Also two files from vi.lib belong to these 151 files. I assume the unsaved ones are the 4 polymorphic VIs. 151 saved files + 4 unsaved polymorphic + 1 unsaved lvlib -> 154 files in project + 2 files in vi.lib.

These recompile bugs are known and will be fixed in the next bug-fix version.

[LAVA 1.0 Content]

These recompile bugs are known and will be fixed in the next bug-fix version.

Then I just have to wait...