LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Run an built (ie.exe) subvi on the front panel of a parent vi

Hello,

I have an application that has a parent vi with a subpanel which runs a child vi inside it. This works great. I am currently working towards turning the parent vi into an standalone executable.

I have also created a standalone executable of the child vi, since it controls a piece of kit that I sometimes use without needing to run the much larger parent vi. Is it possible to display and reference this executable in the parent vi, rather than using the child vi in a subpanel. I'd like to do this so that I can change the child vi, rebuild it and use it separatly and in the parent application without having to rebuild the parent application each time.

Thanks in advance
David
0 Kudos
Message 1 of 9
(4,060 Views)

You can't insert an exe into the sub panel...BUT you could register the sub vi as an ectivex component and use an activeX container instead.

OR

You could call the VI for the subpanel dynamically and put the vi in a support directory instead of rolling into the executable.

________________________________________________________

Use the rating system, otherwise its useless; and please don't forget to tip your waiters!
using LV 2010 SP 1, Windows 7
________________________________________________________
0 Kudos
Message 2 of 9
(4,047 Views)
You CAN do this, but it is not trivial.  You will need to use the Windows API and use the functions related to Child Windows.  This will allow you to bring another program into your LabVIEW VI.
0 Kudos
Message 3 of 9
(4,044 Views)
Hi guys,

Thanks for the suggestions.

I don't fancy the windows API route, I'm not familiar with it and I don't want to spend ages playing around with it.

How do I go about registering the subvi as an activX object. Is it straight forward?

Currently I do call the child vi dynamically, so when I build the parrent app I have to 'always include' the child vi and it's sub vis, which I store in a support directory. What I would like is to be able to hide these vis in the parent vi exe file. Is this possible? Since I'm calling the vi dynamically (through a config file entry) the build has no idea where this vi might be, which is why it doesn't get included in the exe file. I guess what I am looking for is a way to dynamically call a vi during the development stage, which then gets turned into a static reference at build time such that the child vi gets rolled into the exe file. Is there a way to do this, short of replaing the dynamic references with static ones just before I build?

Thanks again
Dave

0 Kudos
Message 4 of 9
(3,995 Views)

I think hidden in the support directory would be good enough, and it lets you replace the VI as you need to...The other option is to hide it in a library. I dont think you can "hide" it in an exe and still have the ability to do what you want with it.

Creating it as an ActiveX object is not too hard either though, you should be able to do a search in the help directorys and find out how to do that quiet easily.



Message Edited by TWGomez on 05-19-2008 07:39 AM
________________________________________________________

Use the rating system, otherwise its useless; and please don't forget to tip your waiters!
using LV 2010 SP 1, Windows 7
________________________________________________________
0 Kudos
Message 5 of 9
(3,988 Views)

well, i tried to understand what you explained but really couldn't manage to get it...

i want to run a standalone .exe file lets say somthing like ie.exe from a push button on the vi interface..

is it possible to do that? what is the simplest way to do it?

0 Kudos
Message 6 of 9
(3,794 Views)

Hi Rabih,

      Subpanels support only LabVIEW VIs.  .NET and ActiveX Containers support a bunch of application/object-interfaces, though, I don't know of a Container that supports an arbitrary Windows application.  The example you gave, "IE", happens to be supported by/for .Net and ActiveX Containers.

 

You'll find the IE browser example here!

 

Cheers!

"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
Message 7 of 9
(3,785 Views)

The usual method for calling a *.exe file in LabVIEW is to use the System Exec VI.  The System Exec VI is located in the Communications palette in LabVIEW 7.x or the Connectivity » Libraries & Executables palette in LabVIEW 8.x.

Refer to the Calling System Exec VI in the <labview>\examples\comm directory for an example of using the System Exec VI.  Or, refer to the attached example for a simple way to run the Windows Calculator program from within LabVIEW (minimum of LabVIEW 8.0 required).

Unfortunately, the System Exec VI does not support calling options following the filename.  In order to call the executable with options, here is what you can do instead:

   1. Create a filename.bat file which calls the executable file with the options following the title ("filename.exe -option1 -option2"].
   2. Then use the LabVIEW System Exec VI to call the filename.bat file, and those options will be ported over.

Here are a few key notes about the System Exec.vi :

    * You can directly call an external file that is not an executable. For example, we will use a file named "My Document.txt". You cannot type "MyDocument.txt" into the command line input of the System Exec.vi. You can, however, type "Notepad My Document", and the System Exec vi will open the .txt file in notepad.
    * Please also note the "Wait Until Completion" input to System Exec.vi. This inputs default setting is True, meaning that LabVIEW will wait until the executable program is done running and gone from memory before LabVIEW will continue with the rest of its code. If this input is set to False, LabVIEW will open the executable, but then continue on with the rest of the LabVIEW code.

 

source: NI website

0 Kudos
Message 8 of 9
(3,777 Views)

Hi Rabih,

      The old thread you posted to was discussing subpanels - and I interpreted your question in that context.

 

My mistake.Smiley Tongue

 

Cheers!

"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
Message 9 of 9
(3,740 Views)