Dynamically plugging "LabVIEW GUIs" to "C#.NET EXE"

[fedexbox1]

Have a C#.NET created EXE. Also have many independednt LabVIEW EXEs which is one form of output (and their source code)

".NET EXE" shall call a "labVIEW_output" from the list of many "labVIEW_outputs".
When called, the 'labVIEW_output' must show up within this EXE's area, with all GUI that it shows currently as an EXE.

Moreover the list of "labVIEW_outputs" is dynamic. So if one particular "labVIEW_output" is removed, added, changed, it will not matter to ".NET EXE".

What are my options to create such a "labVIEW_output" ?

[RavensFan]

Is this a homework question?

[smercurio_fc]

If it is, it's a poorly worded one because I don't completely understand what the goal is.

What do you mean by "have many independednt LabVIEW EXEs which is one form of output"?

[Yamaeda]

Assuming the C# program is the main, you'll have 2 options:

1. Call the labview .exe through system command. Easy but doesn't give much information back to the main

2. Compile the labview programs as DLL's and call the functions as any other DLL. (the better way)

/Y

[fedexbox1]

Hi Raven.

It's a real world situation.

In my understanding, LabVIEW deliverable output forms  may be...

........an EXE  (may not be useful, since no control over it by parent EXE created in C#)

........a DLL (seems better option but not sure if I go that way, GUI etc of related LabVIEW source will be visible when C# calls it. I have created LabVIEW DLL in the past but it did not involve any GUI displays. It was in background)

Also I would like that C#.NET is able to control which place on screen, the LabVIEW deliverable gets launched when it's called.

[fedexbox1]

Hi smercurio_fc.

In my understanding, LabVIEW deliverable output forms  may be...

........an EXE  (may not be useful, since no control over it by parent EXE created in C#)

........a DLL (seems better option but not sure if I go that way, GUI etc of related LabVIEW source will be visible when C# calls it LabVIEw functions in form of DLL. I have created LabVIEW DLL in the past but it did not involve any GUI displays. It was wrapping of math functions in background)

 Also I would like that C#.NET is able to control which place on screen, the LabVIEW deliverable gets launched when it's called.

[fedexbox1]

Hi Yamaeda

Yes you are right, that's why EXE is out of question.

But DLL?

seems better option but not sure if I go that way, GUI etc of related LabVIEW source will be visible when C# calls it LabVIEw functions in form of DLL. I have created LabVIEW DLL in the past but it did not involve any GUI displays. It was wrapping of math functions in background.

 Also I would like that C#.NET is able to control which place on screen, the LabVIEW deliverable gets launched when it's called.

[smercurio_fc]

Have you considered using the ActiveX Server capabilities of a LabVIEW application?

[fedexbox1]

Hi smercurio_fc

Thanks for input.

It is the goal that the "labVIEW deliverable" must be usable in following 2 ways:

- as a child of PARENT.EXE ...example DLL form?

- indepenent EXE running on it's own..........EXE ?..........(not part of big picture but stand alone)

This means, when I create distribution, I will must these above 2 forms (perfectly acceptable). Good news is , this is only at final time (installation creation).

There may be 10 RIGs means, 10 groups creating their LabVIEw deliverables.

Now coming to  your input about Activex

there will be complex modifications that'll be (unncecessary for EXE part of above 2 deliverables &) needed to be done to LabVIEW source, if Activex is to be supported. In addition, Shall activex require that 2 source codes to be maintained for each RIG ?

Given that 10 groups will have to modify this, this option seems less feasible.

My question to you is, 

In above scenario, did you have any specific ACTIVEX funtions that you thought may be useful to integrate LabVIEW and PARENT EXE?

Thanks

[smercurio_fc]

I don't think you completely understand what the ActiveX interface is for. The ActiveX interface basically allows you to control a LabVIEW program from another environment, such as C, C++, VB, C#, etc. The LabVIEW application can still be an application. There aren't 2 source codes for the LabVIEW code. When you build the application you enable the ActiveX Server for the application, and if you build an installer you can check the box to register the app as a COM object. This allows someone writing code in, say, C#, to add a COM reference to their project. This COM reference is for the application.

If you want to investigate the ActiveX Server I would suggest looking at the examples in this KB article: Calling LabVIEW VIs from Other Programming Languages. At the bottom of the article there's a "Downloads" section. Take a look at the callinglvcsharpusingactivex example. That uses LabVIEW as the ActiveX server, but a similar process can be done with a built application that has had its ActiveX Server enabled.