issues building executable

[GregFreeman]

I am building an executable that uses LVOOP and I have a few questions. I have noticed people posting some things like this before, but before I go uninstalling/reinstalling I wanted to check.

First, as can be seen in the screen shot, my build is creating  folders for my classes in the program files directory. In these folders are the VIs. Why?? I'm not including them in the build.

Also, everything runs fine when i run my executable from this build directory (C:\Program Files\Amplifier Control) but if I move the executable out and try to run it, i get the lower-right screenshot popping up.

The strange thing is, the missing VIs are NOT in the C:\Program Files\Amplifier Control directory, so I guess it is finding them in the development directory (I am on my development machine testing the exe).

I can't post the actual project so screenshots will have to do.

Suggestions?

Message Edited by for(imstuck) on 06-01-2010 03:26 PM

[GregFreeman]

To somewhat answer my own question, those files are being moved because of LVOOP seeing file name collisions in dynamic dispatch VIs. C:\Program Files\Amplifier Control is where it is moving them to. Still not sure why my exe is missing files though. When I generate a build preview, they are all there.

[shew82]

I wonder if the Auto-renaming-due-to-conflicts is messing you up... Are you using LabVIEW 2009? If so, consider unchecking the Use LabVIEW 8.x Layout in the build options for the EXE - this will give your exe internal folders so that all of the class VIs can exist within the same thing. It makes EXEs and LVOOP play sooooo much nicer together.

The only thing to watch with this is if you are dynamically calling VIs - the calling logic changes slightly due to the folders... Have a search on ni.com or on the forums - there's a whole bunch of ways to handle this. Of course, if your not calling anything dynamically, then you have nothing to worry about! 

[GregFreeman]

---

shew82 wrote:

I wonder if the Auto-renaming-due-to-conflicts is messing you up... Are you using LabVIEW 2009? If so, consider unchecking the Use LabVIEW 8.x Layout in the build options for the EXE - this will give your exe internal folders so that all of the class VIs can exist within the same thing. It makes EXEs and LVOOP play sooooo much nicer together.

Not using 2009

The only thing to watch with this is if you are dynamically calling VIs - the calling logic changes slightly due to the folders... Have a search on ni.com or on the forums - there's a whole bunch of ways to handle this. Of course, if your not calling anything dynamically, then you have nothing to worry about! 

Not doing this

---

I'm going to play around with the executable more today and see if I can generate anything else that may be helpful in solving this.

[shew82]

In this case its a shame your not using 2009 - they made some serious improvements to LVOOP.  

An alternative that might work (I cant remember if when I used this technique my classes were using inheritance or not....)  is to creating a separate destination for each of your classes (it can be made even tider if you make those destinations an LLB). This way, the classes's member VIs will all be together and it might play nicer with the EXE... 

[tst]

LabVIEW uses relative paths to keep paths to subVIs. As you see, some of the subVIs are saved outside the EXE, so if you move the EXE, you need to move the folders that have those VIs as well. I would have expected it actually to show a dialog searching for the VI, but it's been a while since I've had something like this.

[GregFreeman]

---

tst wrote:
LabVIEW uses relative paths to keep paths to subVIs. As you see, some of the subVIs are saved outside the EXE, so if you move the EXE, you need to move the folders that have those VIs as well. I would have expected it actually to show a dialog searching for the VI, but it's been a while since I've had something like this.

---

Yup, it does show the dialog. The only thing is, I'd prefer not to deliver any VIs with the executable. Is this unavoidable in this case?

Message Edited by for(imstuck) on 06-02-2010 08:41 AM

[shew82]

If you go with the EXE and a bunch of LLBs then you wont have any obvious VIs - things can be obscured further by giving the llbs a different extension (e.g. DLL - I saw that on a devzone article once) Also, even though you technically have VIs inside the LLB, you can use the destination properties to add a password / remove block diagrams etc to make using those VIs inside the DLL in another project even harder.

[shew82]

Here's the devzone article: http://digital.ni.com/public.nsf/allkb/47272B69E2C167DB862574AC006A258B

[GregFreeman]

Thanks for all your replies. In the mean time, I'm just going to deliver it with the needed VIs included. If I get more time, I'll go back and try to troubleshoot more. If it works, it works and thats my number one concern right now.