Can I use ActiveX to embed a front-panel inside another front-panel

[Bmarsh]

If I had a LabVIEW program that has an ActiveX container on the front panel is there a way that the ActiveX control inside that container could in fact be another VI? It seems like it should be possible since LabVIEW supports both the server and client side of ActiveX.

I've looked around for an example of this, but haven't found anything close. And in fact, most of the ActiveX examples I have found are for old versions of LabVIEW.

Any ideas/examples?

Thanks!

[Lab Viewer]

It will be easier to give you some ideas if you can mention what is the goal for this.
I can't see a strong reason to insert 2 ActiveX layers between 2 VIs as long as those VIs can work together without them.

You can try to consider doing one of those VIs job with a VB or C++ application. This way, the activeX integration will be more natural and you can take advantage of some features not included in LV.

[Bmarsh]

Suppose I have 2 different applications, but that each application needs to perform and display the same measurement. Therefore I'd like the measurement to be its own subVI that each application can call.

Ideally, I only want the user to see one window when the operate the applications. I also don't want to copy all the controls and indicators from the subVI to the applications because then when I change something in the subVI it won't propagate.

So, one idea was to use an ActiveX container in the applications to embed the subVI inside the front-panel of each application. If the subVI changes, the changes will propagate, thus true software reuse.

I'd be almost as happy to do the same thing, but use VC++ for the application and make activeX calls down t
o the subVI.

(There are others here that would rather see everything in LabVIEW, but personally I'd rather see it all in C++ anyway!)

My biggest problem is it seems every example that I find for doing anything with ActiveX is for version 5.1 or 5.0 and doesn't work in 6i.

I also haven't found a step-by-step process anywhere that says how to start with a subVI and end up with a registered and ready-to-use ActiveX control. Does this exist?

Thanks

Brad

[Brian_Vibert]

Brad,

I had the same idea as you and did some experimenting back when you asked your question about wizard interfaces. As far as I can tell it is not possible, although I think it would be usefull if it were. Perhaps the folks at NI are listening??

If anyone knows how to implement something like this I would like to know too.

Brian

[Bmarsh]

Brian,

I started revisiting this because I still really hate the way I had to implement the wizard stuff, and I have some other areas where this would be very useful (for instance I have an application that does actual measurements and another that reports on those measurements -- I'd like the share some of the UI code for that -- embedding things on the front-panel would really make everything much easier).

I'm more than willing at this point to have the top-level application be VC++, use an ActiveX container to embed the subVI into my VC++ application, but I can't even find a good set of steps for how to take a subVI and make it an ActiveX control that I can use elsewhere. There are examples out there, but they either involve opening a separate labview wind
ow or they just don't work becuase of version mismatches.

I did forward the question in as a support question as well, but haven't heard any response as yet.

[Brian_Vibert]

Brad,
I hope that they respond and are able to be more help than me. It does seem that there should be a way to do this.

If you get any good information could you share it with the rest of us? Or at least me

Brian

[Bmarsh]

I'll definitely do so.

Brad

[Darren]

Hello all,

Currently, LabVIEW does not allow you to embed the front panel of a VI within the front panel of another VI. However, our developers are currently working on this feature, and it should be in a future release of LabVIEW. For now, one of the best ways to accomplish this functionality is with a tab control. Back in LabVIEW 5.1 I was developing a LabVIEW game, and was forced to use subVI panels that "popped up" for different functionality of my game (selecting game type, entering players names, selecting game length, etc.). However, when LabVIEW 6 came out, I was able to use the tab control to programmatically switch around tabs on my front panel, allowing me to have all of my UI within one VI, and just switch between the appropriate tabs. This techniq
ue is illustrated in my game, which I have attached to this post.

So until LabVIEW supports embedded panels, programmatically manipulating tab controls is probably your best alternative.

I hope this suggestion helps. Good luck, and have a nice day.

Sincerely,
Darren N.
NI Applications Engineer

[Bmarsh]

This is great until you want to reuse one of the tab panels in another program (please don't tell me cut&paste is a real reuse option).

So the question becomes, does National support ActiveX to the extent most vendors do and actually supply an ActiveX control that I could use to embed LabVIEW into a VC++ program (just like I can do with IE, or RealPlayer, etc). I have a good feeling I know the answer, but I'd like someone at National to come out and admit it.

[Darren]

Hello,

From what I understand, one of my colleagues has been discussing this issue with you, so I won't repeat everything he has already said. Basically, LabVIEW can function as an ActiveX server in that you can programmatically launch VIs through other programming environments...however, LabVIEW does not currently function as an ActiveX Control that can be placed in containers. This functionality will be indirectly available in future versions of LabVIEW in two ways...within LabVIEW, you will be able to have embedded panels. Outside of LabVIEW you will be able to have a panel browser control that will allow you to browse through VIs in memory within an ActiveX Container...keep in mind that both of these functionalities will not be available until
a future version of LabVIEW.

Also, in the future it would probably be best (just for the sake of efficiency) for you to keep your questions directed either to our e-mail support system or the Developer Exchange, but not both.

Have a wonderful day.

Darren N.