Interface wrapped objects and VBScript

Today we'll do another round of our (actually – mine) favorite activity - VBScript bashing. Specifically, we're going to talk about VBScript's inability to work with certain Interface objects. This question in SQAForums made me understand that I'm not the only one who deals with these problems, and that maybe it's time to share my workarounds.

Here're some quick facts: While VBScript is quite a backwards programming language (hence the "Script" in VBScript), it can work with sophisticated objects that were written in other languages. So, if you got an object with a COM interface, you can create it via the CreateObject command, and use it with your everyday VBScript commands. Moreover, if you write your own .Net DLL, you can create it within QTP's VBScript context via the DotNetFactory command. This can fool us into believing that life is indeed good, and that there's no object too complicated for VBScript and QTP.

BUT, this turns out to be wrong. There are objects which are too complex for VBScript, and as a result, too complex for QTP. These objects are certain types of Interfaces, which wrap around the application's actual objects and hide them from VBScript. If you have no idea what an interface is, don't worry – it's not very important for our purposes. The bottom line is that very complex applications are prone to work with interfaces, which means that you won't be able to access their internal object structure.

To give an example which bugged me for the better part of a year, if you're trying to automate an ESRI (geographic) based application, and you need the map's coordinates, you're kinda screwed. You can try accessing the properties of the map object all you want; it won't do you any good, because it's an interface, not a "regular" object.

So, how can you know if the object you're trying to access is an interface? You could read the object's documentation, but a much quicker way is trying to access it from QTP. Run a script which can lead you to the object, and pause it. Go to the debug window, and write the path to the run-time object. You'll see that QTP marks it as (Object). But now, try accessing the some internal property of this object (e.g. QTPObject.Object.SuspectROObject.SomeProperty). It doesn't really matter which property, nor if the object even has this property, because you'll see QTP spits out an "Object needed" error. This means that even though QTP knows this is an object, it can't access it. These objects will appear as var-type 13 (vbDataObject).

For now, this problem only surfs with complex applications and controls. However, it's only reasonable that these objects will become more and more dominant in the coming years, so be prepared.

OK, we've got an object which holds much needed information, but we can't work with it in QTP. How can we workaround that? I've found 3 methods for doing that:

Try finding a way to make it work: I don’t KNOW these objects are inoperable in VBScript, I've just given up finding a way to do so. It took me the better part of a year to give up, and I would LOVE to hear of some real solution to the problem.

Write extensibility: QTP .net add-in has a remarkable feature, which allows you to write your own QTP shell for unknown .net objects. The extensibility works with the .net objects within a C# context, which means that it can rise above any VBScript limitation, and specifically, it can work with these problematic objects. You can find out more about writing extensibilities in the QTP help files.

Write a custom DLL to do your dirty work: This is quite similar to the extensibility workaround, though it's much simpler and easy to implement. You can write a .Net function which receives the problematic object, works with it, extract the needed information from it, and returns it in a form which VBScript can work with. This is usually not a problem since at the end of the day, deep down the object hierarchy, you probably only need a string, number, or array value (e.g., the object is an abstract geographic point, but you actually need an X double value, and a Y one, easily structured as an array).

Once you got your function written packed as a .Net DLL, you can create it within QTP (using the DotNetFactory utility object). Then it's very simple to pass the problematic object to your function, get the answer, and continue the script without any problems.