VI execution state incorrectly marked Broken in unsaved .lvlib

[littlesphaeroid]

I wrote a pre-build action to verify that all VIs, including statically linked VIs, in the build are not broken before starting the build. This has saved a lot of time, since LabVIEW often doesn't find broken VIs until well into the build process.

In many cases I have found that VIs would be marked as broken when they were not, and today I discovered that this occurs when the lvlib they are contained within has changes and has not been saved.

To reproduce this error, I can run a build successfully, then right-click on one of the VIs in the library that is the source of the build, and change the VI's name. When re-running the build, this or another VI will problematically be determined to be broken by my pre-build action, and the build will fail. Without the action, the build is successful. Right-clicking on the lvlib in the project and selecting Save solves the problem. The build will now be successful

This seems like a bug to me.

My next step is to include a save library step in the pre-build action.

[Ben]

Maybe I am missing something...

VIs in a lvlib are prefixed with the library name. Why would you think changing the VI name and not saving the library so that is records the changed name is a bug?

Trying to understand,

Ben

[natasftw]

A bit of a history lesson might help here.

In ancient times, libraries were of the llb type.  It seemed like a great idea.  If you have a bunch of similar VIs, you could pass the llb file and EVERYTHING was passed.  One file, all the functionality.  They had a fatal flaw, however.  PCs aren't immune to corruption.  If a single VI became corrupt, you lost everything in that LLB.  That was pretty sad.

In order to make this more manageable, there's now the lvlib.  This creates a header file, of sorts, to manage all of the contained items in the library.  The library links to all of its members and each member links to the library file.  If anything changes, these break.  The break is to let you know the library isn't in its known good state.  Things you can do are change the library (without saving) or moving files on disk, as an example.  In these cases, it's intentional that things "break" to let you know there are changes and allow you the chance to fix these changes.  If things corrupt now, you'll lose a single VI that you can recreate and keep the rest of your library.  It has pros and cons.  But, what you're seeing would almost certainly fall under the realm of expected behavior.

[littlesphaeroid]

The bug is that the VI is not broken, nor is the library. The VI can be opened and run. The executable will build without error. BUT, in the pre-build action I wrote, the Execution State property of one or more VIs will be "Broken". (To recap, in hte pre-build action, I get a list of all top level VIs in the library, and all statically linked VIs in the library, and check the execution state of each, looking for broken VIs). To my understanding over nearly 20 years of using LabVIEW,  A broken VI is one that will not run, and whose run button has the broken arrow on it. Thus, the report that it is broken must be incorrect, hence my belief that this is a bug. It is in fact that the library itself is unsaved, but this is also not broken.

Ben, perhaps you are confused because I provided a way to reproduce the bug. Renaming of the VI does not break it or the library. The issue of not-broken VIs being marked as broken in the execution state property has been noted before, but I can't find the relevant discussions now. It took me a long time to figure out the solution, so I thought I'd share it here.

[Norbert_B]

Honestly (without digging into the source of the error) i think you have a bad development process/habit here.

Building *something* with the application builder is a step during development where you (as the developer) are confident that all sources are in a working state. A working state of sources for any programming language means that the sources are implemented and tested (debugged). Personally for me that implies/requires that the sources are saved and pushed to Source Control.

Following that philosophy should prevent anyone to run into that issue at all.

[Ben]

I can not speak one way or the other since a "bug" is a condition where software fails to comply with specifications. Since I do not know what the spec is for a sub-VI having been renamed but it's caller not being saved.

It would most likely be called "not a bug" if submitted to R&D because calling it a bug would mean someone would have to change something.

Sorry I can not be of more help,

Ben 

[littlesphaeroid]

Dear Norbert. Actually, you are wrong. Building something with the application builder may be part of a lengthy debug process aimed at determining if the built application acts the same as the source code, which as you know sometimes it does not. or it may be part of debugging a pre-build action. Or it may be part of packaging code to [post to a colleague, whether or not the code works. 

In my case, I am building test libraries, and a big part of testing these libraries is running them in a test sequencer. Sometimes this requires an iterative build process.

But frankly, whether or not my process is broken has nothing to do with this problem or its solution. Thanks for your input anyway.