Compatibility with VB dll

[Maz]

I am presently developing on two platforms. We use TestStand 2.01 to control execution of our ActiveX VB dlls. When an update to the vb code is integrated on one of the platforms, we copy that code (including TestStand) to the other platform. At that time we either recompile the vb dll or manually register the copied dll using regsrvr32. However, when we run, TestStand doesn't "see" the dll. We have to go and re-link every ActX step in our sequence (via the "Specify Module" button)file to the updated vb dll. Is there a TestStand setting that I'm missing? I've done this kind of thing on other projects with no problem. Please help. I have hundreds of ActX steps in my sequence files.

[David_Jackson]

Yes - we have the same problem here. The way I've found around it at present is to open my TestStand sequence in a text editor, then perform a find and replace operation on all changed ActiveX references (e.g. Server, Interface ID's) within the sequence. I then reload the sequence in TestStand.

This has worked for me so far, and is a lot quicker than having to manually refresh all of the ActiveX calls. I would be interested to know if there is a way to do this in TestStand though.

Regards,

David

[Mikef]

I'm going to take a shot at this, which could be your problem.

We use VB ActiveX as well, but the compatibility problem that we had dealt with every time the VB was recompiled, it would no longer work with the TS code (we were using TS 3.0, now 3.1).

The fix was to edit the properties of the .vbp file (right click in the VB enviornmnet), on the Component Tab, set your Version Compatibility to "Project Compatibility".

Incidentally, you can also debug into the VB code by setting the Debugging Tab "Start Program" to TestStand. When you start the VB code, it will start up TestStand. Any breakpoints you have set in your VB code should then work with the instance of TestSTand that VB starts up.

Mike

[Scott_Richardson]

Take a look at the Compatibility Options for Visual Basic section in Chapter 5 of the TestStand 3.x Reference Manual. This describes the issues with compatibility with external programs for Visual Basic DLLs. In a nut shell, it is recommended to use Project Compatibility while developing code and switch to Binary Compatibility when you release a system. When you switch to Binary Compatibility you should keep in there and only add new methods or classes. You should not change the names or prototypes of existing methods or properties.

[Mikef]

One more issue that I ran across in developing the VB ActiveX (I'm using the ActiveX EXE rather than the DLL because I have some forms that are used), was that the Class module should have the Instancing set to "5-MultiUse" in the Class Module Properties.

This clears up the "No creatable public component detected" error message.

Don't remember the details on this, but I found that it was required for what we were doing. Maybe Scott can explain why this is necessary.

Mike

[Scott_Richardson]

Mike -
The options are:

"Private" means it is an internal class that is not exported from the DLL or EXE. TestStand cannot use it.

"Public not creatable" means that the class is exposed for external use but the object cannot be created externally, but instead returned from another class. TestStand cannot create it but can call methods on it.

"MultiUse" means exported and creatable. TestStand can create the object and call its methods.

"GlobalMultiUse means that the methods are exported and you do not have to create an instance to use it. I believe that this only applies to VB projects and not TestStand. TestStand will see these as "MultiUse"