By opening the top-level and checking out the Error Window, you can determine if statically-referenced VI's are broken. A Mass Compile can flush the rest of the broken VI's. Are there scenarios where these methods are insufficient?
Currently the project does not keep all VIs in memory. To do features like the one you request would require that we keep the VIs in memory so that we know when they become broken (many changes to subVIs that break caller VIs cannot be known unless we actually have the caller VI loaded and see how the change affects the caller). How far do you want us to go with keeping the whole project in memory? I ask because this isn't the first feature request that would necessitate that.
Some projects do not have one top-level. This is where a wrapper VI comes in handy, and in that case, yes, you can easily find broken VIs. The projects we work on might not be our own. Without knowledge of how the project is arranged, it's hard to know where the broken arrows are. A mass compile for the sake of finding broken stuff just isn't intuitive to me, but it would work. Maybe this feature could do just that, with a Notice: Mass Compile will take place to find broken VI's. OK, Cancel.
Aristos,
Seems like temporary loading would work to run the feature. This feature would just find VI's sitting on disk that are broken.
> Seems like temporary loading would work to run the feature. This feature would just find VI's sitting on disk that are broken.
Should we do the search for missing subVIs? If we were doing an actual load, LV would search for missing subVIs, and might find them. Does a subVI count as broken if it has missing subVIs but we would find them if we actually did the searching? More than searching, there's also time spent mutating VIs into the current version. If we actually take the time to do a load, would you want us to prompt to save when we unloaded to avoid expensive work the next time you did the same search?
Does a subVI count as broken if it has missing subVIs but we would find them if we actually did the searching? Two questions really. YES, it is broken. NO, don't do the searching. If a VI has a missing sub-VI, it is broken. You double-click the VI in the broken VI list and when it opens, you'll troubleshoot it yourself.
If we actually take the time to do a load, would you want us to prompt to save when we unloaded to avoid expensive work the next time you did the same search? NO.
I'm not sure what the fuss is about. VI Analyzer finds Broken VI's, why can't this?
> I'm not sure what the fuss is about. VI Analyzer finds Broken VI's, why can't this?
VI Analyzer basically can find "VIs on disk that were last saved as broken." It has always bugged me that VI Analyzer can flag a VI as broken, but when I open it, the VI is not broken. This can happen for lots of reasons: maybe the last time the VI saved, a subVI that it uses was saved as private, and when it loads into memory, the library has already been edited to make the subVI public. Maybe a typedef was out of date, but the typedef edits have been reverted. Maybe a file was missing on disk when it was last saved, but that file is there now, so the VI loads not broken, even without searching. Or maybe LV searched and found it.
Worse would be the false negatives -- a VI was saved last as good, but
one of its subVIs has had its connector pane changed, so when you load
it, the VI will be broken. If you only look at disk, the VI will report as good.
There are tons of reasons why a VI on disk that was saved broken won't be broken when it comes into memory. I'm slightly surprised that VI Analyzer hasn't gotten flak for this, but then, VI Analyzer is typically run over a set of VIs, all of which are saved and out of memory, so there are fewer cases like this (although the "file was missing and is now present" cases still apply). Inside the IDE, in a project that is currently being edited, though, I think that these sorts of things would be even more common, particularly the false negatives.
In short, I really don't think this feature would be useful unless all VIs in the project are kept in memory at all times (in which case the Error List Window already gives you this info) or we do a temporary load/unload, with the attendent penalties.
