Jump to content

LVOOP EXE w/ Overloaded Class Methods


Recommended Posts

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!

Link to comment

...

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

  • Like 1
Link to comment

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

post-906-127179667262_thumb.png

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.

Link to comment

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! thumbup1.gif

  • Like 2
Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.