activeX in executable

[caz]

Hi all,

I'm having the problem of an ActiveX control working on the development computer and not working in an executable on a target machine that does not have LabVIEW installed. I've seen a few posts similar to this but I was wondering what the best way to approach this is? For instance, currently the AX controls get installed when installing a 3rd party app. The .ocx files are then found in the corresponding c:\program files directory. On the development machine, I've been dropping a AX container and then right clicking and picking the control. Because it shows up in the list, I'm assuming its getting registered when installing the 3rd party software. I've tried installing the same 3rd party software on the target but I get either an error 3001 when using the container or error 97 when using automation open. What else do I need other than the .ocx file to use the AX control in a labVIEW executable? Would it be possible to create another LabVIEW .exe that my installer would call to correctly place and register this AX control so I don't have to run a full installation of the 3rd party software? And if so, can the .ocx file live anywhere and is there anything else I need to do to use the control in a labVIEW executable. Also, in my .vi calling this control, how should I do it? ActiveX container? Automation Open? And does the paths on the development and target machine have to be the same? I know its a lot of questions so anything you might add would be helpful.

Thanks,

caz

Message Edited by caz on 07-20-2009 05:25 PM

[smercurio_fc]

Is your target running LabVIEW Real-Time? I ask just to eliminate that possibility, as my understanding is that ActiveX is not supported on LabVIEW Real-Time, and you'd get that error.

Assuming not... For a single ActiveX control you can just use regsvr32.exe to register a control. However, not knowing that control you're referring to, there may be more to it.

As far as a container or Automation Open, it depends on whether you need a visual interface for the control. Does it?

[caz]

Nope, not running RT and I don't need a visual interface. The AX control I'm using is for communicating with a Baldor electric motor drive so I just need to access its properties and methods. Currently I'm installing the control by installing the Baldor front end software and my app works fine on any machine that has LabVIEW installed. One thing I'm a little uncertain on is if I'm using references appropriately. My app is basically a state machine and I have a main cluster that gets passed around through a shift register. Before entering the state machine, I initialize the cluster in a subvi and in this subvi is where I have the container for the control. The cluster is type def'd and I'm not sure if I used the right reference control for the AX component. I think I just copied the reference from the AX container and placed it in my cluster control. In the image below, the reference in the cluster constant that the MintController reference is replacing is referencing the same AX control. I can right click the contstant and choose a specific AX control from the list. Shouldn't this constant be more general? For instance, if a new AX control is released I would only want to update the one in the container and not the one in my cluster control. I guess for now I would be happy getting my executable to work on the target machine and then maybe perhaps going a step further and figuring out a way to properly install and register the AX control without installing the Baldor software using my own .exe to launch as part of my installer.

[caz]

I should also add that I've been testing a much more simple code compiled to an executable that just uses either the container or automation open and doesn't have any subvis or clusters etc. This code simply gets the reference to the control and tries to read one property and then closes and this isn't working at all. I've installed the AX control on both the development computer and the target using the same version of the Baldor software. Could there be an issue with paths? For instance, by right clicking and choosing the AX control I want on the development machine, how does the executable on the target know where to find the .ocx file? Does it matter what directory the executable is run from?

[smercurio_fc]

I can't be totally sure, but I'm guessing the reason why it doesn't work in an executable is that with an executable the front panels of VIs (with the exception of your top-level VI) is stripped. This may cause your reference to break since you are relying on the ActiveX container, as opposed to instantiating the class using Automation Open. You can test this by overriding the "Remove Panel" setting for the subVI that has the ActiveX container and set it to not strip the front panel.

You would need to look at the documentation for the control to determine how to use the control programmatically without relying on the container. It's likely to be relatively straightforward.

[caz]

Thanks for the info about front panel stripping, I suspected it but didn't know for sure. However, in my last post I mentioned that I've been trying to get this AX control to work in a single top-level vi to no avail. On my development machine I can right click automation open an choose my AX control to use but I wonder how the executable is finding the correct control. If I build the .exe and simply copy and paste it and the other supporting files from the build to my target machine how does it know where to find the AX control? I must be missing something since the .exe works fine when run on my development computer but not on the target. Is this an issue of where the .exe is run from on the target machine or do I need to specify the location of the AX control in the source code in a more strict way instead of relying on the right click menus? Totally confused about this.

[smercurio_fc]

Sorry, I hadn't seen that last message you posted. It seems you posted it at the same time as I posted my reply, and I hadn't seen the email notification. I'll try to look at this further. In the meantime let's see if anybody else wants to chime in.

[caz]

Thanks smercurio, I have been approaching this on a trial an error basis for the last couple days but if I described the hoops I have to go through to build an .exe and finally get it copied to my target laptop you would think I'm crazy. I figured I should get some expert opinion before going through the 30 min process of making one simple change for testing. My gut feeling is I need to put the .ocx file with the project somehow so that when the .exe is built it can be located relative to the app. I'm just not sure what all goes with an AX control. Is it just the .ocx file or is that file just a helper for some other .exe that's called. Also, does an AX control have to be "registered" or is there a way to use it by placing and referencing it appropriately in my LV app.

[smercurio_fc]

ActiveX controls are registered with the operating system, not the application, so there's normally no need to include the control unless it's a custom control that has no installer so you need to register it yourself.

I was trying to play around with this a bit, and so far I haven't been able to reproduce your problem. Where did you get the ActiveX control that you're trying to use?

[caz · Accepted solution]

After some more digging I found the problem. On the LabVIEW 8.6.x known issues page issue 118215 states that activeX controls fail to load in the 8.6 Run-Time engine alone and that the USI component must also be installed. When I created the installer for my app I had just checked off the Run-Time engine and by including NI-USI it now appears to be playing nice. I would have never thought to check the known issues page had it not been for Darren's recent nugget (wiping forehead and exhaling deeply).