Build Error: Determining which VIs have a "Bad" block diagram

[kegghead]

I'm trying to build my application which contains a few classes that implement VI overrides, hence by default produce name collisions when attempting the build. I'd rather not have external directories with the relevant VIs sitting there, I'd much rather them be compiled into the EXE like all the other VIs. So I tell the build to prefix the objects of each class with a string that will produce unique names for each VI in the inheritance chains. The problem is when I try to build the application, it fails saying it cannot save a bad VI without it's block diagram. The entire error is below:

Error 1502 occurred at Invoke Node in
AB_Source_VI.lvclass:Close_Reference.vi
->AB_Build.lvclass:Copy_Files.vi
->AB_Application.lvclass:Copy_Files.vi
->AB_Build.lvclass:Build.vi
->AB_EXE.lvclass:Build.vi
->AB_Engine_Build.vi
->AB_Build_Invoke.vi
->AB_Build_Invoke.vi.ProxyCaller

Possible reason(s):

LabVIEW:  Cannot save a bad VI without its block diagram.

Method Name: Save:Target Instrument

None of the referenced VIs or classes in the error are ones I wrote. Any advice on...what this means?

[gmart]

You didn't list a version number but I'm guessing it's 8.5. This error only occurs if you try to add the prefixes? On that note, while adding the prefixes might results in the files all being inside the EXE, the application probably will not work if you are using dynamic dispatch VIs. The reason is that the overriding is done by name so if the names of the the child classes don't match the base class, the overriding behavior will not work. If you don't want directories outside of the EXE you can manually create destinations that are LLBs and target the class and member VIs to that LLB. There will still be files outside of the EXE but not directories.

Additional error reporting was added in 8.5.1 which would list the problem VIs. If possible, you could try building the application with 8.5.1.

[kegghead]

Right, I'm working with 8.5, I still haven't gotten around to using the 8.5.1 disks that were shipped to me a while back.

The program is perfectly happy with the VIs living outside the executable in their own directoreis, problems only stem when they're embedded with a name prefix in one way or another. I suppose what you're saying makes sense, if the resolution of the proper VI is done by name at run time. That does seem like a flaw though on the part of LabVIEW, I'd expect the VIs to be named internally such that having the same VI names as part of different classes shouldn't cause a problem...especially since using class abstraction demands it.

From what you've said, I'm getting a feeling that having external files for classes that implement overrides is unavoidable in LabVIEW, is this so?

I'll try 8.5.1 and see if anything more helpful comes up, thanks for the tip.

-Michael


Message Edited by kegghead on 06-05-2008 07:22 AM

[gmart]

The behavior of files with name conflicts being outside the executable is a known issue. The creation of directories happens "automatically" when LabVIEW detects the conflicts. You can manually choose where the conflicts go (per my suggestion) but ultimately, they will still need to go outside of the executable.