Lots of problems building a large executable with LVOOP classes

[billings11]

I don't see any deal breakers in that issue list, so I'm sticking ith 8.2.0 for a while.

[AristosQueue (NI)]

> 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 for someone
> to do this to get an exe to work, that is a MAJOR bug by NI and
> 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.

[billings11]

Ha ha I'm sure most are libraries that get loaded in.  There are only a couple hundred lvoop vi's.

[THANG NGUYEN]

Hello,

Base on your experience solving the issue with building the executable file with LVOOP, I would like to ask for your help with my specific case:

First, this error I met

=============================================
An error occurred while building the following file:

D:\My Application\Classes\DAQ Control\Private\Internals\GetData.vi

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.

I highly appreciate your help.

Thang Nguyen

[AristosQueue (NI)]

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.

[billings11]

Thang,

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-2007 08:43 AM

[billings11]

Aristos,

Thanks for teh info, but I've learned my lesson.  I'll wait for 8.5.1.

[AristosQueue (NI)]

> 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.

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.

[billings11]

Well for the first time for me.  All the 8.X stuff really is lumped together in my head since it is all so new, and it all got released practically on top of each other.

Aristos,

Is there a way within a vi itself (other than the titlebar) to view and/or specify what class or library a vi belongs to?

Message Edited by billings11 on 08-29-2007 01:54 PM

[gmart]

View>>Browse Relationships>>This VI's Library/Class. Once the library or class is open you can edit the ownership of the VI.