Accessing Classic COM Objects with Scripting Languages

Creating classic COM objects with C++ is very difficult, and to a large extent .NET has eliminated the need to create classic COM DLLs for applications in a Windows environment. But classic COM objects are still needed for many types of system programming tasks, and legacy classic COM objects will be around for decades. Let me describe a few ways to call classic COM objects using some scripting languages. Suppose you have a classic COM object realized as Utilities.dll and which contains a class named CMyFunctions and associated interface named IMyFunctions which in turn contains a method named TriMax(x,y,z) that returns the largest of integers x, y, and z. A JavaScript call example is:
var obj = new ActiveXObject("Utilities.MyFunctions")
var result = obj.TriMax(3,7,5)
You can access the COM object using ActiveX technology, passing in the object’s ProgID, which is stored in the System Registry and which you can think of as an alias for the COM object. A VBScript call example is:
Dim myObj
Set myObj = CreateObject("Utilities.MyFunctions")
result = myObj.TriMax(3,7,5)
This is pretty much the same. A PowerShell call example is:
$obj = new-object -comObject "Utilities.MyFunctions"
$result = $obj.TriMax(3,7,5)
Here the new-object cmdlet marshalls up the COM object. Accessing a COM object from Perl looks like this:
use Win32::OLE;
$obj = new Win32::OLE("Utilities.MyFunctions");
$result = $obj->TriMax(3,7,5);
You have to use the Win32::OLE language extension. As you can see, the ideas behind calling classic COM objects are essentially the same for most scripting languages. The choice of "best" scripting language for this task depends mostly on non-technical factors such as how familiar you are with a particular language and how much a particular language is used within your development environment. 
This entry was posted in Software Test Automation. Bookmark the permalink.