11-03-2014 06:49 AM
I would expect that list to contain something like: Compiled source file from older LV version.
This is my assumption: Your VIs are created with an older LV version than you are currently using.
Norbert
11-03-2014 06:59 AM
In the properties menu you can also copy the path to the VI in question so you can paste it into Windows explorer if you want to open the VI itself. I do this if I want to do something like update rev info on a VI that needed to take a change.
For some reason you can't do this from the error list.
11-03-2014 01:30 PM
I guess I should have made it clear I wanted to know how to Stop this behavior.
It began after I uninstalled LabVIEW 2014 64-bit and installed LabVIEW 2014 32-bit, because the recently purchased MathScript RT Module will hang LabVIEW 64-bit (although, why many other legacy 32-bit functions are properly handled). Apparently, this constitutes a "version change", which is what I found in ALL my subVIs under List Unsaved Changes.
THE SOLUTION:
I forced a mass compile with CTL-SHFT Run Arrow, closed the top-level VI and told it to Save All.
I no longer see a flag that the subVIs need to be changed when I merely open one.
11-03-2014 01:47 PM
Yep, that would do it. You could have also done a mass compile. FYI, the Separate From Compiled would have avoided this issue for you.
11-03-2014 04:23 PM
I did do a mass compile. "Separate from Compile" is not a good option for me because I am building run-time executables.
11-03-2014 06:13 PM
@wildcatherder wrote:
"Separate from Compile" is not a good option for me because I am building run-time executables.
That only becomes a factor if you are dynamically calling VIs that are not included in your EXE. When you build the EXE, you have the compiled code in there. The Seperate From Compile is only for the VIs when they are out on their own. It makes source code control a lot easier.