Including External LVOOP Public Methods in Executable

[wesramm]

Hello,

I have an application which on the top level must 'talk' to several different instruments; a LabJack UE9 (USB) , a Newport Motion Controller (USB-Serial), etc. When I wrote the drivers for these instruments in LV, I used the LVOOP functionality and created individual Classes with public methods for each of the different devices I need to communicate with. Sounds logical to me, anyway.

In my top-level application, I call the public methods (and must include local instances of the LVOOP classes) for those independant instrument-specific classes. In the development mode, everything works peachy. However, when I go to build the application executable (build), I get some weird behavior;

Firstly, with the default setting in 'Additional Exclusions' in the Build Properties of 'Remove as much as possible', I get errors when the builder gets to my independent classes. I get the message:

"An error occurred while building the following file:

C:\Documents and Settings\Wes Ramm\My Documents\Projects\RDT\LabJack\Class\Common Methods\Get DO Line State.vi

The VI became broken after disconnecting type definitions. Open the Build Specification and choose a different option on the Additional Exclusions page."

Ok, it seems that the class object is not linking, but I can get around that by selecting the second option in 'Additional Exclusions' ; 'Remove unreferenced project library members'. BUT, when the build is done, I get a couple of subdirectories with vi's named for all the different class methods for each independent that I am calling. There is no front panel or block diagram for the vis, so it looks like they are correctly 'included' in the build, but it seems cumbersome to include these subdirectories.

I even tried to 'add' the independant classes to the project by 'Add Folder', but got the same behavior.

The classes that I made are not a part of the top level VI, and the top Leve VI is not a member of any of the classes, so this I think is the crux of the matter. However, I am instantiating only the public methods, and the problems only pop up when I try to build the executable.

Am I missing something? Is there a more elegant way to do this? Any advise / tutorials / knowledgebase articles you can point me to?

The tree for the directory structure for my build looks like this (for reference)

\\Application Directory\

Executable

\Config

\ Class One.lvclass (first external class that I am calling in my top-level vi)

\ Method 1

\ Method 2

\ Method 3

\ etc

\ Class Two.lvclass

\Method 1

\Method 2

\Method 3

\ etc

[Chris Davis]

could it have something to do with this post?

[Aristos Queue]

A) There's a known issue with building LVClasses into EXE/DLLs when choosing the various "remove" options. Classes were really intended to be coherent wholes and no provision was made for breaking them into pieces when building apps. It's being addressed, but for the time being, you have to include the typedefs (so that the private data control doesn't disappear) and not remove unneeded VIs (since the dynamic dispatch VIs aren't directly called by the caller VIs, the build system thinks they're not needed).

B) Yes, the dynamic dispatch VIs save outside of the EXE/DLL. And, yes, it is cumbersome. The problem is that the DLL/EXE is effectively a single directory internally and so no two VIs of the same name can be saved inside the EXE/DLL. Of course, LVClasses almost always have two VIs of the same name -- that's how overrides work. So as a workaround, we made the dynamics save outside of the EXE/DLL. The diagrams and panels are stripped, as you noted. A future version of LV should address the file name limitations of EXE/DLLs.

[wesramm]

Roger that. I can live with this, as it is hardly a problem, just unexpected. Thanks for your reply.

Wes

QUOTE(Aristos Queue @ Mar 1 2007, 12:24 AM)

A) There's a known issue with building LVClasses into EXE/DLLs when choosing the various "remove" options. Classes were really intended to be coherent wholes and no provision was made for breaking them into pieces when building apps. It's being addressed, but for the time being, you have to include the typedefs (so that the private data control doesn't disappear) and not remove unneeded VIs (since the dynamic dispatch VIs aren't directly called by the caller VIs, the build system thinks they're not needed).

B) Yes, the dynamic dispatch VIs save outside of the EXE/DLL. And, yes, it is cumbersome. The problem is that the DLL/EXE is effectively a single directory internally and so no two VIs of the same name can be saved inside the EXE/DLL. Of course, LVClasses almost always have two VIs of the same name -- that's how overrides work. So as a workaround, we made the dynamics save outside of the EXE/DLL. The diagrams and panels are stripped, as you noted. A future version of LV should address the file name limitations of EXE/DLLs.

Roger that. I can live with this, as it is hardly a problem, just unexpected. Thanks for your reply.

Wes

QUOTE(Aristos Queue @ Mar 1 2007, 12:24 AM)

A) There's a known issue with building LVClasses into EXE/DLLs when choosing the various "remove" options. Classes were really intended to be coherent wholes and no provision was made for breaking them into pieces when building apps. It's being addressed, but for the time being, you have to include the typedefs (so that the private data control doesn't disappear) and not remove unneeded VIs (since the dynamic dispatch VIs aren't directly called by the caller VIs, the build system thinks they're not needed).

B) Yes, the dynamic dispatch VIs save outside of the EXE/DLL. And, yes, it is cumbersome. The problem is that the DLL/EXE is effectively a single directory internally and so no two VIs of the same name can be saved inside the EXE/DLL. Of course, LVClasses almost always have two VIs of the same name -- that's how overrides work. So as a workaround, we made the dynamics save outside of the EXE/DLL. The diagrams and panels are stripped, as you noted. A future version of

LV

should address the file name limitations of EXE/DLLs.