> But I should not have to select this option for the build to work.
> I want you know know that if it is ever necessary
> to do this to get an exe to work, that is a MAJOR bug by NI
> should be considered unacceptable.
Let me assure you: The issues with AppBuilder weren't uncovered until after the 8.2 release. Both
of these workarounds are definitely considered bugs and have been fully
fixed in the next release. There's no way that a bug like that would be
allowed to stand unaddressed. Only a single customer has had to
use the "enable debugging" workaround -- everyone else has only had to
use the "do not exclude anything" option. I'm extremely happy to hear
that you don't need the debugging workaround.
2004 VIs? How much of that is actually part of LV classes and how much
is subVIs for other libraries? I ask because you might be able to take
the title of "largest LabVOOP application" that I know of. The current
reigning champion is a yet-unreleased app inside NI.
The VI became broken during the build process. Open the Build Specification and enable debugging to include the front panel and block diagrams. =============================================
I tried to enable the debug and select this selection: "Do not disconnect type definitions or remove unreferenced members." , but I still meet this warning:
============================================= A name collision occurred during the build. VIs were renamed to protect the build. If any dynamic calls were made to the following VI(s), unexpected behavior may occur ... =============================================
Because in each class I have similar VIs, for example: GetData.vi, is it the reason of the warning? Then when the building process come to the last stage, which means I see the message build completed, the LabVIEW start to crash.
FYI, in the new LV8.5 release (announced Aug 3 2007), all of the known
errors that occurred between LVClasses and AppBuilder are fixed.
The 8.5 version still saves dynamic dispatch VIs in a subdirectory next
to the .exe file and not inside the .exe file. This is, for the moment,
expected behavior. But let me assure this forum, just as I have other
forums, that I consider this a temporary solution. This behavior will
be changed in a future LV version so that all the VIs are saved inside
the .exe file. It wasn't addressed in 8.5 as we put priority on making
the build succeeed overall.
I never had that particular message come up for me. But I've done labview for a while and the first thing I worried about when I started using LVOOP was namespace collisions. In classes you have to use the same vi names throughout, but that goes against every development rule I've ever made for myself.
I have figured out this much:
When you drag a vi into a class you are actually modifying the vi itself as well as the project. Somewhere inside the vi it is saving what class that vi belongs to. So even if you open the vi without the project window open, the vi will show on the titlebar that it is a member of the class. So this is how labview must be handling namespace collisions - by actually changing the internal vi name when you drag it into a class. For the first tiime a vi filename isn't its function name.
Is it possible that you have a sub-class that isn't inheriting properly from the main class? I would think that something like that could lead to the error you are seeing. The builder probably doesn't want to see the same method names unless the classes are properly inherited.
PS - I've found with LVOOP applications CTRL-SHIFT-RUN ARROW is often necessary before any build. It mass compiles by hierarchy when you do this instead of by directory like when you mass compile through the menu option. Often I found that fixes vi's that break during the build process, (although I'm not sure why).
Message Edited by billings11 on 08-29-200708:43 AM
> When you drag a vi into a class you are actually
modifying the vi
> itself as well as the project. Somewhere inside the
vi it is saving
> what class that vi belongs to. So even if you open the
> the project window open, the vi will show on the titlebar
that it is a
> member of the class. So this is how labview must be
> namespace collisions - by actually changing the internal vi
> when you drag it into a class. For the first tiime a vi filename
> its function name.
Not for the first time. This has been true since LV8.0 with Libraries
and XControls. All types of Libraries (.lvlib, .lvclass, .xctl, and the
new in 8.5 .lvsc) namespace their VIs. The libraries know what VIs they
own and the VIs know which library owns them. Check out the online help
for libraries for details.