LVOOP EXE w/ Overloaded Class Methods

[Noxious]

I found a few other topics relating to similar issues but none that got me to a solution.

This topic discusses what I am seeing while I am using LV2009. I will attempt to explain:

I have a project that when built into an exe, generates folders (named like classes) that contain vi files used in the project in an overloaded fashion.

The build also throws a warning :

"LabVIEW prevented a file name collision during the build. Duplicate file names cannot be copied to the same destination. You can rename files as part of the build process to avoid name conflicts.

The following files were moved to a unique location:

...\Classes\Database\ProgrammingDataReadWrite\Write EUI64.vi

...\classes\drivers\device\uut\Write EUI64.vi

...\classes\drivers\device\find_device.vi

...\classes\drivers\device\uut\rex\find_device.vi

...\classes\drivers\pattern_match.vi

...\classes\drivers\device\instrument\xstick\pattern_match.vi

...\classes\drivers\device\instrument\xstick\find_device.vi"

These vis where all created using the "New" > "VI for Override..." right click option from a child class the modifying the new vi to do something different than the parent class.

For deployment reasons I want all my builds to boil down to a single executable (nor do I want my source floating around). Any idea why this is happening and how I can fix it?

Thanks!

[Grampa_of_Oliva_n_Eden]

...

For deployment reasons I want all my builds to boil down to a single executable (nor do I want my source floating around). Any idea why this is happening and how I can fix it?

Thanks!

I believe your classes are worthless with the parent class. If you build the parent into the exe then anyone that wants to steal your child classes will not be able to do anything with them.

Ben

[Jeffrey Habets]

This is pre-LV2009 behaviour.. You probably should check this setting in your build specification:

It should be unchecked.

[jgcode]

This is pre-LV2009 behaviour.. You probably should check this setting in your build specification:

It should be unchecked.

I think if you upgrade your project from e.g. 8.6 to 2009 this box gets checked automatically. Also here is some discussion regarding the new build format.

[Noxious]

This is pre-LV2009 behaviour.. You probably should check this setting in your build specification:

It should be unchecked.

Sure enough, that did the trick...

Thanks y'all!

[Chris O]

Just make sure that if you have any relative file paths in your code, you check that they still work. The LV2009 directory method in executables mirrors the directory structure on your computer. In LV 8.x, all your VIs had their path under the executable, which is why you got your warning. If you like to put things like config files in your support directory, you used to be able to strip a VI's path twice and then move to your support directory. Now, since the directory structure is maintained, you can't know how far down the hierarchy your VI is. BUT! there is a new function in LV2009 that will get you where you want to go. In the File I/O > File Constants palette, there is an Application Directory constant that will take you straight to the folder containing your executable. Its very nice!

[Aristos Queue]

The LV 2009 layout is what we *wish* we'd had in LV 8.2, but didn't, so now that we have it, we have to have build options to maintain functionality for existing apps. Read the upgrade notes -- the new 2009 mechanisms are WAY better than anything LV has had in the past, both for loading dynamic VIs from your EXE and for mapping to VIs that are still sitting outside your EXE.