How do I quickly update the ActiveX automation references in my VIs when the ActiveX interface changes?

[wdmot]

Hello all,

I joined a test automation team in the middle of a large project and inherited a huge set of VIs (over 700) and associated architecture for this automation (not to mention the several thousand TestStand sequences).  Another part of the project is being developed by our customer, who is using VB 6.0 to create ActiveX components which we need to use in LabView to access their hardware.  They've already invested a large amount of time developing these ActiveX components, and they are not finished -- meaning the ActiveX interfaces will be changing.  Every time they send updated ActiveX components, I have to re-write many, many VIs including updating a couple strict typdefs.  This process takes way too much time and is mind-numbing and prone to error or omission.

Unfortunately I can't post any of the VIs because of a NDA.  But perhaps a bit more detailed explanation would help.  TestStand calls a VI to open and get an ActiveX reference for automation (which it stores in a variant).  It will pass this reference into any VI it calls to perform specific functions through this ActiveX interface.  For example, one VI that may be called passes this automation refnum into another, which passes it to another, which passes it into another to get the actual ActiveX reference stored in that variant (through a Variant To Data call with a strict typedef of the ActiveX component wired to the type input).  [See the attached image of this sample VI hierarchy: the far left icon would represent TestStand, and the far right is the strict typedef.]  Any of the VIs in the chain might use ActiveX Property or Invoke nodes, and it can break at any one of those when the ActiveX component changes.  It's easy to fix each one, but since there are so many VIs it takes a very long time.

Is there any way at all to do a massive search/replace or something to make the ActiveX references update?  I realise that even though property or method names stay the same from one version to the next, they are different references.  Is there a way to update these based on name if you give it the base ActiveX reference?

Thanks in advance for any help!

Tom Williams

[SamboNI]

Hello wdmot,

Unfortunately, there does not seem to be any way to do a search and replace for Automation Refnums such that new functions available in the ActiveX interface are reflected in your VIs.

Best of luck with your application,

[Ben]

Tom,

Could you please post a set of VI's that demo this issue?

Editing the typedef is not enough?

Confused

Ben

[wdmot]

Ben,

Unfortunately I can't post any VIs that would demonstrate the problem because the ActiveX components are confidential.  I'll try to develop my own ActiveX dll that will demonstrate it, but in the meantime, in hopes that another picture will help, I've attached an image of a block diagram (with some names changed to protect confidential information) of one of the lower level VIs from the hierarchy I posted.  In this example, the "Automation Refnum IN" is an input with a type definition linked to the strict typedef based on the ActiveX automation dll that has changed.  I updated that typedef, but as you can see the output to the "Class1" indicator is broken.  If I delete the "Class1" indicator and select Create->Indicator from the Class1 property node, and then wire the new "Class1" indicator to the connector pane, the VI is fixed -- at least at compile time.  In most cases there is also a runtime problem where the reference obtained by one of the intermediate property nodes is null, so the property or method node that uses it fails (e.g. "_VNManager.Networks" property returned is 0, so the "_Networks.Network1" property node fails).  To fix this problem, I have to delete the wires between the property nodes, and one by one select a different property/method, then select the correct property/method and re-wire.  There seems to be a bit of "jiggling the handle" to get it to work though.

I don't know if the ActiveX developer changed anything in this class, but if he did, he didn't change the name of this class.  I would like to have to modify the VI only if a class, property or method has changed name or been removed.

Does that all make sense?  Thanks for any pointers or help!

Tom

[Ben]

This will be rough not being able to poke around.

Is "class1" a type def?

If you replace all occurances of class1 with typedef's you should only have to update the type def.

RE; the property node.

Can you wrap all of the activeX nodes in sub-VI's so you only have to update the sub-VI (similar to what is done with the 3-d graph)?

Trying to help,

Ben

[wdmot]

The "Class1" indicator is a refnum to an ActiveX class, same kind of thing as the green wires between the property nodes.  It's being passed back to another VI that will access some of its properties or methods.  Quite often (pretty much once for every VI like this) one of the intermediate property nodes also returns a runtime error basically saying that a compatible automation reference could not be obtained, and I have to re-create the property nodes to fix it -- essentially the same as re-creating the Class1 output indicator but I don't know about the error until runtime.

There are many VIs like this, so replacing all of these indicators with typedefs would be a major project -- and I'm just trying to use what someone else developed so I can do my work (which is mostly writing tests in TestStand).

As for wrapping the ActiveX nodes in sub-VIs, I thought that's what is being done here.  At each level (_TestEnvironment, _VNManager, _Networks, Network1, Class1...) there are anywhere from 5 to 30 sub-classes, properties or methods available. Wrapping each ActiveX node in a separate sub-VI would require writing several hundred more sub-VIs.

I think I'm going to have to push this problem back to the customer and their other developer who made these VIs.  Thanks for your help.  I'll post again if I find a solution, but please feel free to post more ideas.

Tom

[AdnanZ]

Tom,

A workaround to this problem is discussed in the following forums post:
How do I update my ActiveX controls without breaking existing VIs?

Have a great day!

[tbd]

Hi Tom,

      This idea isn't a cure, just an attempt at damage-control...

It might be possible to create and use a "static" library - made from one of your existing distributions.  If all VIs were synchronized with this one "static" library, then, immediately after obtaining a reference to the real object, cast the refnum to the same object in the static library.  The bad news is: you won't be forced to reconcile all of a new object's properties and methods - (but they'll still work if their interface hasn't changed.)  To get at new/changed properties/methods, just don't do any casting.

Once the library changes settle-down, I'd remove the cast-to-static and reconcile the code with the real library\object(s.)

Wrappers? I'm sure you've thought of this (but here-goes anyways - - )... Depending on how often the same properties/methods are accessed, there might be some value in wrapping/re-using them in a sub-vi - to help minimize the number of places that need to be "fixed" with every new library(?) 

Cheers.

[wdmot]

Thanks tbd.  Unfortunately I don't think it would work.  I left out a bit of information to keep from getting too complicated: the ActiveX components are actually part of an application that is launched by the ActiveX.  I'm not sure if the customer could build it into a static library instead.

Does .NET alleviate this problem?  That is, if the application and ActiveX interface were converted to .NET, would we still have to update the VIs when things were added or changed?  If this would solve the problem, I'll try pushing our customer to do that.  If not, we'll be billing them for many many hours of VI conversion every time they make changes that we need to make use of.

Tom

[tbd]

Hi Tom,

      While your situation is certainly more complicated than I understand, it still sounds like you're responsible for LabVIEW code that uses an externally (customer) provided ActiveX library.  I don't think you'd need your customer's help to create a new "static" (my word) Library - to start-with, I'd just rename the DLL (or OCX, or TLB) and try using it as a source for object references (for casting-typedef purposes only!) - thus allowing subsequent/underlying code to use a new library's objects as if they were still in the old library.  Of course this inserts a risk that an object's interface really does change and needs to be "reconciled" at some method/property node but it avoids the current risk and labor of opening/editing tens or hundreds of VIs that don't need any changes.

Thank you for trying to clarify   and don't worry if I'm still missing something - it's a chronic state

Cheers. 

Message Edited by tbd on 01-05-2007 03:08 PM