Calling VI inside .EXE

[LAVA 1.0 Content]

I have a sort of test executive I created in labview that calls other labview built exe's and embeds them in subpanels, this technique has worked well for me, and has widespread use at my facility. The path to the VI would simply be <path to .exe/toplevel vi name.vi>, this worked because a LabView exe is basically just a folder with all the VI's in it. In 8.20 this technique is not working, it basically says the path to the VI is bad. I was in a closed door session at NIweek for large application development and they mentioned that you could no longer view the contents of an exe by simply changing its extension to a .llb. I asked if the technique I was using would still work , and I was told it would. It is very possible I did not convey the question properly, or perhaps there is another way to accomplish this task, and that is why I was told it could be done. So in the hope that there is a way, does anybody out there no how to acomplish the aforementioned technique in 8.20?

[Michael Aivaliotis]

Todd, Have you seen this thread?

http://forums.lavag.org/index.php?showtopic=2165

I'm not sure if it covers your problem but there is a lot of info in there.

[Dave Graybeal]

Thanks for the Response Michael, I didn't see anything in that thread that seemed to match this exact problem though so I thought It might be best if I explained what Todd was trying to describe a bit better.

Problem description: We are trying to load a vi that exists in an Exe into a subpanel of a VI that does not exist with that same Exe.

Problem Demo:

Attached is a zip file that contains 4 projects (Child App, Child App V80, Parent App, Parent App V80). Under each of these folders are the vi's used in each project as well as the built executables for each project. If you run the Parent App V80 build under LabVIEW Version 8.0, you should see a VI pop up that displays the Child App V80 vi in a subpanel (just a VI that says This is My Exe). If you then run the Parent App Build under LabVIEW Version 8.2, you'll see that the same example produces an error instead of embedding the VI. If you look at the code it is the same method used in both version.

PS. Make sure to unzip the Zip File into the folder "C:\Exe Access Issue" , this is so you don't have to change the Vi paths and re-build the exe's to test it.

Hopefully someone will know another method of doing this same thing. If anything sounds unclear let me know and I'll try to describe it better.

Thanks In Advance,

Dave Graybeal

Download File:post-4149-1155660605.zip

[kennoncotton]

I have a sort of test executive I created in labview that calls other labview built exe's and embeds them in subpanels, this technique has worked well for me, and has widespread use at my facility. The path to the VI would simply be <path to .exe/toplevel vi name.vi>, this worked because a LabView exe is basically just a folder with all the VI's in it. In 8.20 this technique is not working, it basically says the path to the VI is bad.

Todd,

Yep in 8.2 we made a change that "fixed" being able to take a .exe (or .dll) rename it to a .llb and view its contents, at least on Windows. Some people have been worried about this being a "security" hole because you can see the VI names and connector panes if you have the same version of LabVIEW the executable was built in. But you can't see the block diagrams or most of the front panels (just the ones you specifically kept), so I don't know how much of a "security" issue it was but it certainly bothered some people. Now if you had debugging turned on in 8.0, App Builder kept the front panel and block diagrams so it really did have your all code, but you shouldn't be handing out debuggable exes.

The reason we changed this behavior wasn't for this security issue, but for compatibility with the upcoming Windows Vista. In Vista you can / need to sign your executables (I'm pretty sure XP supports this as well and 2000 might) to show they are legit and if you signed a LabVIEW built EXE or DLL made in 8.0, the EXE/DLL stops working. So we changed the way we put the VIs into the EXE/DLL so that signing the EXE wouldn't "destroy" it, and as a result you can no longer see the contents of one by renaming it to be a .llb or access VIs in it by path from outside of the EXE.

I was in a closed door session at NIweek for large application development and they mentioned that you could no longer view the contents of an exe by simply changing its extension to a .llb. I asked if the technique I was using would still work , and I was told it would. It is very possible I did not convey the question properly, or perhaps there is another way to accomplish this task, and that is why I was told it could be done. So in the hope that there is a way, does anybody out there no how to acomplish the aforementioned technique in 8.20?

As the person who told you that would still work, I think I did misunderstand your question or didn't communicate my answer well, so let's get it in writing .

You can still call VIs that are in an EXE, obviously ones you are calling directly/statically but also dynamically through VI Server. But you can only call them dynamically from a VI is in that EXE or running in that EXE's application instance. So if c:\myapplication.exe\a.vi dynamically calls c:\myapplication.exe\b.vi it will work but if c:\foo.exe\d.vi tries to dynamically call c:\myapplication.exe\b.vi it won't work. The reason is sort of related to the Application Instances that Michael referenced, in that c:\myapplication.exe\* is a valid directory for VIs that are in the Application Instance created when c:\myapplication.exe is run, but more that .exes are no longer essentially .llbs (at least on Windows, the didn't change on Mac or Linux).

So what do you do about this change of functionality? There are a couple of choices I see:

1. You are basically treating these VIs as exported VIs. So one option would be to create a DLL out of them and have all your EXEs call that DLL. This would make your executable code more modular and is probably the best design choice of these solutions and maybe the least work.

2. Another would be to configure the EXE build specification to have these VIs reside outside of the EXE in a folder or LLB next to the EXE. The problem I see here is making sure all the subVIs the VI you are calling needs are not in the .exe otherwise they won't be found. The work here would be to keep up with the subVIs to make sure they are all outside the EXE.

3. A source distribution of the exported VIs would sort of be a combination of 1 & 2. It would provide DLL modularity, as you would call the exported functions dynamically and would be making the LLB I mentioned in 2 it's own build. Probably the same amount of work as #1. And since you are using LabVIEW to call the VIs, it probably makes more sense than #1 (DLL is best for C++ calling VIs) and would be my recommendation.

4. Enable the ActiveX interface for the EXE you are calling into and use the VI Server ActiveX interface to run the VI (Get a VI Reference, Set the Control Values, Run the VI, Get the Indicator Values), this is a lot of work for the caller of the function and a little for the build specification.

5. If you enable the VI Server for the application you could open an Application reference to that port on your local machine and then use Open VI Reference and call the VI as you did in the past. While it isn't much more work for the caller, you do have to keep your ports numbers straight and keep up with the right settings in the ini files for the EXEs.

Alright I've typed enough,

Kennon

[LAVA 1.0 Content]

Kennon,

Thank you very much for the detailed explanation. After carefully digesting the possible solutions, I determined that for my use case 4 or 5 would be the best possible solutions. I quickly ruled out 4 because I realized all the subpanels I was using would have to be changed to Active X containers, and this was not practical for various reasons. So that brought me to 5 as stated below.

5. If you enable the VI Server for the application you could open an Application reference to that port on your local machine and then use Open VI Reference and call the VI as you did in the past. While it isn't much more work for the caller, you do have to keep your ports numbers straight and keep up with the right settings in the ini files for the EXEs.

Kennon

I have never used VI server to open a LabView built exe, but with the help of my great new Reference book (Labview For Everyone, third edition ) I found that I needed to create an INI with the sme information relative to VI server found in my LabView ini and name it the same as my exe. This is what I added:

server.tcp.enabled=True

server.tcp.access="+127.0.0.1"

server.tcp.port=3364

it would appear that the application reference is correct but when I try to open a reference to the VI (c:\myapplication.exe\b.vi) I get the same error 7 I was getting when I tried just opening the VI reference without passing it the Application reference. What Am I missing :headbang: .? Thanks in advance for any more help you or anyone else can provide. :worship:

[kennoncotton]

Thank you very much for the detailed explanation.

No problem. Sorry this post took a while, it has been a busy week figuring out what we need to be working on based on all the feedback from NI week.

After carefully digesting the possible solutions, I determined that for my use case 4 or 5 would be the best possible solutions. I quickly ruled out 4 because I realized all the subpanels I was using would have to be changed to Active X containers, and this was not practical for various reasons. So that brought me to 5 as stated below.

Hmm, I was thinking that you would be using this VIs as subVIs not as subpanels. From the testing I've done, I can run a VI from another EXE as a subVI (call by reference) but I can not insert it into a subpanel. It sounds like you have some common UI modules/reuse code, not just a common API or non-UI reuse code, I think my option 3 of doing a source distribution makes the most sense for your setup.

I have never used VI server to open a LabView built exe, but with the help of my great new Reference book (Labview For Everyone, third edition ) I found that I needed to create an INI with the sme information relative to VI server found in my LabView ini and name it the same as my exe. This is what I added:

server.tcp.enabled=True

server.tcp.access="+127.0.0.1"

server.tcp.port=3364

I've got a nice autographed copy of that same reference sitting on my desk here, Thanks Jim.

it would appear that the application reference is correct but when I try to open a reference to the VI (c:\myapplication.exe\b.vi) I get the same error 7 I was getting when I tried just opening the VI reference without passing it the Application reference. What Am I missing :headbang: .? Thanks in advance for any more help you or anyone else can provide. :worship:

You might be having the same problem I had initially in that I didn't have localhost wired into "machine name" on Open Application Reference. I have to admit I didn't compeletely write out a test for this option before I suggested it. But I've cobbled one together between meetings yesterday and finished it up this morning.

Basically the attached project builds 2 EXEs. One contains A.vi and B.vi. A.vi opens a reference to B.vi that shows you can use a path with <foo>\some.exe\<bar>.vi in an exe to call VIs that are in that exe. The other EXE uses VI server to access the first EXE and call B.vi, it also tries to insert it into a subpanel, which fails. To show you can view the panel I added an open panel and a loop with a wait to keep it around after the reference closes. One caveat is the first EXE must be running (well at least open) for the second EXE to access it's VI Server, the old method of calling a VI right out of another EXE didn't require it be open.

So this should show what is possible using VI Server (or the ActiveX server) abilities of an EXE, but I do think you need a more modular approach on these common features and create a source distribution(s) for them.

Hope this helps,

Kennon

Download File:post-624-1155914696.zip