Portability of LabVIEW application which calls custom ActiveX component.

[Chuck Uhlrich]

I have written a LabVIEW application which uses an ActiveX component written by a co-worker in Visual BASIC 6. The ActiveX component contains several public methods and numerous properties and collections. The component is distributed on CD, and uses an installer to copy files and register the component with windows(I don't know a lot of details about that). My LabVIEW application consists of several top level VIs that call lower level VIs that invoke ActiveX methods. The general structure of these 'method' VIs is as follows: access a global Automation Refnum, feed that into an Automation Open, feed the resulting Automation Refnum into a SubVI that sets properties and collections as required(Automation Refnum is passed through the property node primatives and is passed back as an indicator). This returned Automation Refnum is fed into an Invoke Node primative which invokes the desired method. Then another SubVI is called to to read property and collection values populated by the method. Finally, the Automation Refnum is fed into the Automation Close.
This all works fine on my machine, but not on other's machines. That is my problem. I want to be able to share my work with other workers at our site. To distribute my application, I instruct them to install the co-worker's ActiveX component with it's installer, then to copy my collection of VIs onto their hard drive. I then have them create some customized VIs from templates that I provide. Finally, I have them do a Mass Compile of the folder containing my collection of VIs. When they finish with that, many of the VIs in application are broken. When I look into why, I find that all the Automation Refnums have lost their references to the ActiveX component(the errors reported are Wire: class conflict, and Wire: refnum conflict). The errors can be repaired by going into each and every VI that contains an Automation Refnum and doing a right-click|Select ActiveX Class and select the desired item from the list. This is tedious to do for every installation, and I am hoping there is a way of getting this to work automatically. My OS is WinNT 4.0, and the LabVIEW application was written in version 5.1. I have tried installing it on other which have LabVIEW 5.1, and 6i. Any help would be appreciated. Thanks.

[Nadav_Chernin]

Such problem exists when you just copy ActiveX to another machine but not register it. Try to make registration of ActiveX by calling from command prompt the next command:

regsvr32 NameOfActiveX.ocx

[Chuck Uhlrich]

Perhaps I wasn't clear on this point. The ActiveX component is installed on the target system with it's installer which registers it. In fact, I have compared the registry of the original development machine(where the software works) and the target machine(where it doesn't), and the entry "My Computer\HKEY_CLASSES_ROOT\\Clsid" is the same in each.

[JRA]

This is very strange. I have never heard of this before other than times when the ActiveX component is not properly installed. I built a VI using an Automation Refnum and then recompiled it but the link was not broken afterwards. Could you paste a copy of the VI here and I can try it on my machine to see if it exhibits the same behavior? Just let me know if that would help.

[Chuck Uhlrich]

I received your reply. The ActiveX component that I am attempting to communicate with is rather large, and possibly proprietary. I am attempting to put together a smaller generic component that exhibits the same behavior. I don't know if this matters, but the component was developed in Visual Basic 6.0 and is compiled with a .dll extension. I mention this because some replys have referred to the component as an ocx. Further, the component uses a third-party commercial serial communications package which IS an ocx. Does that muddy the water any?

[wiebe@CARYA]

Is the full version of LabVIEW installed? With LV6.0.1 I've had problems
with the runtime engine.

The runtime engine did not register nicont.dll and nicontdt.dll. The problem
was solved after I registered these myself.

When it's the full version (develompent version), the problem might be that
the machine is not registered as a development machine. This can be solved
by installing a MS Office program (e.g. Word). Because these applications
install Visual Basic for Applications, the installation also sets a
'development' tag somewere in the registry. Exactly how this works, I don't
know.

I've had a 'new' pc, and after installing the runtime engine, I've had the
first situation. When I got the .exe working, the .vi version still did not
work!

Good luck. Please share your findings!

Regards,

Wiebe.

"Chuck Uhlrich" wrote in message
news:506500000008000000A6670000-1031838699000@exchange.ni.com...
> I have written a LabVIEW application which uses an ActiveX component
> written by a co-worker in Visual BASIC 6. The ActiveX component
> contains several public methods and numerous properties and
> collections. The component is distributed on CD, and uses an
> installer to copy files and register the component with windows(I
> don't know a lot of details about that). My LabVIEW application
> consists of several top level VIs that call lower level VIs that
> invoke ActiveX methods. The general structure of these 'method' VIs
> is as follows: access a global Automation Refnum, feed that into an
> Automation Open, feed the resulting Automation Refnum into a SubVI
> that sets properties and collections as required(Automation Refnum is
> passed through the property node primatives and is passed back as an
> indicator). This returned Automation Refnum is fed into an Invoke
> Node primative which invokes the desired method. Then another SubVI
> is called to to read property and collection values populated by the
> method. Finally, the Automation Refnum is fed into the Automation
> Close.
> This all works fine on my machine, but not on other's machines. That
> is my problem. I want to be able to share my work with other workers
> at our site. To distribute my application, I instruct them to install
> the co-worker's ActiveX component with it's installer, then to copy my
> collection of VIs onto their hard drive. I then have them create some
> customized VIs from templates that I provide. Finally, I have them do
> a Mass Compile of the folder containing my collection of VIs. When
> they finish with that, many of the VIs in application are broken.
> When I look into why, I find that all the Automation Refnums have lost
> their references to the ActiveX component(the errors reported are
> Wire: class conflict, and Wire: refnum conflict). The errors can be
> repaired by going into each and every VI that contains an Automation
> Refnum and doing a right-click|Select ActiveX Class and select the
> desired item from the list. This is tedious to do for every
> installation, and I am hoping there is a way of getting this to work
> automatically. My OS is WinNT 4.0, and the LabVIEW application was
> written in version 5.1. I have tried installing it on other which
> have LabVIEW 5.1, and 6i. Any help would be appreciated. Thanks.