ActiveX doesn't check on startup anymore?

[Kevin.Shirey]

We are heavily using ActiveX and recently built labVIEW drivers for them in 8.5.1. Why is it when the DLLs are not installed and registered is the code completely runnable? A force recompile doesn't break the VI like it used to? Is there some ini option for LabVIEW to re-enable this? 

I've read on sites that a bug was fixed from 8.2.1:

49HH05G0 Registering an updated ActiveX COM library breaks VI and requires relinking all Invoke Nodes

Also I read an ini option that does NOT work advertised:

checkActiveXLibs=True

It is vital for our project to check all of our drivers are indeed correctly linked before running the executable. We need to track which VIs are broken to ensure they are all contained in our driver folder. 

Many Thanks, 

--Kevin

[Chris_G.]

Hello Kevin,

 

I must admit that I am a bit confused about the behavior you are experiencing.  Are you: (1) Updating the DLL for a registered assembly? (2) Unregistering an ActiveX assembly? (3) Updating a DLL and the ActiveX assembly seems to be automatically updating? Or (4) none of the above (please describe with detail the unsavory behavior and steps to reproduce if possible).

It is true that there was a bug fix in LabVIEW 8.5 (49HH05G0) which had to do with ActiveX COM libraries.  Basically, if one updated the COM library with a new version of the assembly, a VI that pointed to the assembly would break, and require one to re-link all invoke nodes linked to the assembly.

As far as the ini option that you read about, that is an old tag from previous versions of LabVIEW, and is probably no longer valid. 

If you run the VI that is calling the assembly, does it throw errors?  If not, does it run the old version of the assembly, or the updated version (assuming it has been updated during this process)?  Please let me know when you have a chance so that we can better assist you.

[Kevin.Shirey]

Are you: (1) Updating the DLL for a registered assembly? (2) Unregistering an ActiveX assembly? (3) Updating a DLL and the ActiveX assembly seems to be automatically updating? Or (4) none of the above (please describe with detail the unsavory behavior and steps to reproduce if possible).

(3). The problem is the DLLs we are using are third party vendor specific which may be different on customer platforms and need to be handled in the code at run time. The framework was built in LabVIEW 7.1.1, currently been in LabVIEW 8.5.1 for over a year. In previous versions, when the vendors upgraded thier DLLs, it would break our LabVIEW code; we would relink and save knew it would work. Now, we lose that 'feature' and forced to completely resdesign our framework to test these scenarios. We've begun to find all of the calls to ActiveX and .Net routines and build a set of specific drivers and in a unqiue directory. To find if all the routines were correctly migrated, are plan was to install it on a naked machine, get a list of all the broken VIs, check paths to be sure they are all in our driver architecture. We have no way of checking that automatically now. Our project is 2000+ VIs, too much to look at by eye. 

If you run the VI that is calling the assembly, does it throw errors?  If not, does it run the old version of the assembly, or the updated version (assuming it has been updated during this process)?

The code is nestled in so many places, we may not exercise every function call to see if we get an error upon a class not being registered.We need to validate all our DLLs calsl are contained within a specific set of VIs and directories, also to verify all calls are properly registered before building an executable. Is there any way this is doable as in previous versions of LabVIEW??

We are currently looking to upgrade to 8.6 to use the scripting features. We hope to enter a block diagram, right click on all property nodes and invoke nodes and event callback nodes to be sure a valid menu is up. If it is not registered, there is no menu in any of the nodes. Not sure if this is feasible however?

http://decibel.ni.com/content/docs/DOC-4973

Thanks, 

--Kevin

[Chris_G.]

Hello Kevin,

It sounds like you are registering a new version of an ActiveX assembly,

and the VIs which call it are automatically updated with the new

version's properties, methods, and sub-classes.  As you can imagine, it

was a big pain point for people to be calling external components, and

then have to manually re-code their VI when updating the ActiveX

assembly.  As you have pointed out, you took advantage of this

"feature", and used it as a way to check and make sure that all of the

ActiveX calls you were making were valid.

If you need confirmation of any property or invoke nodes that contain

values that are now invalid with the new assembly, you will still have

errors in the error list for the VI.  For instance, if registered type

library contained "Class A" with "Property B", but in the new type

library "Class A" no longer has "Property B" and now has "Property Z"

instead, you will receive an error on the property node that once

accessed "Property B" similar to the following:

All of the wires will not be broken, but the actual property being

referenced by the property node will appear in black, indicating that it

is no longer valid.  The same goes for invoke nodes.  So if you are

looking for a simple hand-check/inspection to see if the ActiveX calls

are still valid, this should not be a problem.  Broken wires are not

necessary to detect invalid calls (calls that do not exist in a new

version of a type library). 

Also, if you wish to search all existing property nodes and invoke nodes

(not just ones that no longer work), then you can use the find tool

(CTRL+F) to find all instances of a function (property nodes, invoke

notes, automation open, register event callback node, etc.).  However,

if there are no errors in the VI, then all ActiveX calls should be

properly registered.  As for verifying the behavior of their functionality, obviously that would take an actual functional test.

Do you wish to check just for functions that contain invalid references (like the example above)?  If so, LabVIEW should automatically give you this information already.  If not, are you looking to verify all functions, whether they contain an invlaid reference or not?

[Kevin.Shirey]

In LabVIEW 8.5 and 8.6, this is not correct. I've attached a pic.

When the ActiveX routine is not registered, or not using the same version, or can not be found, the property node right click shows No Methods, yet not breaking the VI, the wires, not listing any errors or warnings! How are we supposed to know this at compile time??

[Chris_G.]

Hello Kevin,

 

Thank you for posting the screenshot, as it pointed to the discrepancy between what you and I were doing in our Vis.  The behavior that I noticed was when opening an automation reference to the ActiveX server directly in the VI’s block diagram.  After updating the ActiveX server being called with a newer version (replacing the older one), the old automation reference is invalid, and as a result the VI is broken:

   

When opening the reference from a SubVI (as your VI appears to be doing), the main VI does not exhibit the same behavior after the ActiveX server is updated:

It seems reasonable to me that a reference coming from a SubVI could actually be a reference to a specific type library (since the calling VI does not know/care if the type library is registered in the GAC or not).  As far as the calling VI is concerned, the type library could be in a different folder, specified by the program by its path instead of being in the GAC.  For this reason, I believe that this is desirable behavior, but I will check with our R&D team to be sure and post back here as soon as I do.

[Chris_G.]

Hello Kevin,

 

It appears as though this is expected behavior, for the reason that I mentioned in my last post.  The fact that the Automation Open is being done from within a SubVI shields the operation from the calling VI from knowing if it is opening a registered ActiveX Server, or just a type library on disk in a private folder. 

 

So, for your situation, we will have to explore some work-arounds to the process that you were implementing to check for any invalid methods/properties:

 

(1)    Perform the Automation Open function in the calling VI and not a SubVI.  This will provide some better error information at edit time about what invoke/property nodes contain valid references.

(2)    Use the find tool (CTRL+F) to look for all property nodes, and then all invoke nodes in opened VIs (you can open the entire project that they reside in first).  It is not glamorous, but you can then manually check each one to make sure that they all have valid properties/methods being referenced. 

 

Item (2) should not be too unlike what you are already doing, since it sounds like you are visually inspecting for broken wires in your previous procedure.  Hopefully one of these will meet your needs.  What do you think?

[Kevin.Shirey]

Hi,

The solution I designed will help us a lot more. I decided to use VI Scripting in some hacked ways to get what we need to tell if references are broken but now it is automated. Possibly someone else could use something similar in the future?

We can gather all property nodes and invoke nodes using the VI Scripting. It can get all terminals of the node including the reference in and out and all the property calls which we store as well. This tool helps us document what ActiveX calls we are making, to what DLLs, TLB, .Net routines.

The scripting gives us the variant of the data type of that terminal of the reference. We first find out if it is a LabVIEW based node by trying to cast the variant to a LabVIEW based class using the error. It required making a for loop and trying close to 65 class types. If any are successful, we save the type as LabVIEW and move on.

Next, we read the type in the variant. An example is below taken from the front panel. There is no way to read the same variant type ‘string’ as seen on the Front Panel on the BD, very frustrating! I cast the variant to a flattened string and read the hex string to obtain the 3 hex reg strings of Class, Type and Interface. This enables us to check the registry to make sure the reference is indeed registered. If it is not, we know the VIs are broken and can report them. By reading the registry, we can also gain information about the real Class, Type, Interface and physical path of the call.

'SA_Analyst142._SA_AnalystCalls': Automation reference of class
TypeLibCLSID {40D21155-A0D4-4CD4-ACCC-B9550B015188} Ver 1.0
CoClassCLSID {39CDD8A4-DF6F-4BF6-A14B-7C830E603DEE}
ObjectCLSID {67C0D669-3594-4CFE-B65C-44A2124AAFF5}

.Net routines are a bit more tricky, but we are able to at least get the root of the message for most routines. These reference text are a bit more variable to convert, so if there was a cleaner way, it would be ideal. Again, if there was a way to convert the string you see on the front panel for Variant Type, we would be all set.
Name: System.Diagnostics.Process, System, Version=0.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 Main Application Instance

I can send more pictures or code if anyone is interested.