Comparison

If you have used VBScript, you are probably familiar with common COM interfaces like WScript.Network and Scripting.FileSystemObject. These are interfaces that sit on top of the Windows API. When using FastTrack, however, these types of COM interface become superfluous, as FastTrack uses the Windows API directly, voiding the need for late binding.

By way of comparison, let's look at a very simple example of connecting a share in three different ways:
It immediately becomes clear why the native FastTrack version is preferred: When you write the script line in the script editor, it is validated that ConnectShare is, in fact, a valid command and that its parameters are also valid. The other two versions require you to know that the way to connect a network share is to instantiate an object from the WScript.Network COM interface. You also have to know that this interface has a method called "MapNetworkDrive" and which parameters this method can take. The only way to validate that everything is syntactically and semantically correct, is to execute the script and see if it fails.

When to use COM with FastTrack

The example above was very simple; when working with more complex COM integration from scripts in any scripting language, script construction becomes chaotic and often impossible to make robust. For this reason COM was introduced as late as version 6.2 in FastTrack, because COM interfaces must be used as a last resort. As a general rule, do not use COM if you can avoid it. The use of COM interfaces is an "expensive" way for an administrator to facilitate the Windows API. You will probably never actually need to work with COM interfaces, as FastTrack has native functionality to replace COM interfaces that reflect the API of the operating system.

However, you will need to work with COM interfaces if you need to automate Excel, for instance. Automating Excel is outside the scope of FastTrack because it will never provide native functionality for the thousands of methods and properties in Excel's COM interface. Let's look at a simple example of using COM with Excel:
In this case we have created a COM object by using the CreateObject function, specifying "Excel.Application" as the COM interface. On this object we are getting the value of the property "Version" and displaying that through the ShowMessage command. When Office 2010 is installed, this is the result:



This would be useful information for a logon script if, for example, you are unsure that every computer on the network has been upgraded to Office 2010. Instead of trying to "guess" the installed version from registry keys or similar, why not just ask the application itself? In case a computer has an old version, you could store the version information in a log file (AppendFile command) or a central xml file (WriteXMLValue command), send an e-Mail to the HelpDesk (SendMail command) or simply ask the user to contact HelpDesk at their convenience. The latter could look like this:

Advanced COM example

The COM functionality of FastTrack can also be used for more advanced COM tasks. The following sections will explain the details of FastTrack's COM syntax, but let's look at an Excel automation example first, to give you an idea of what advanced COM usage might look like. This type of COM usage in general could be useful for creating a report summarizing computer information. We will however simplify the example to simply insert static numbers, use various custom formatting and then insert a formula to sum up cell values. The report will look like this:




To get this example to work, a deeper knowledge of the Excel COM interface is needed from the vendor. In this case, the interface is well-documented here on the Microsoft Developer Network (MSDN). Armed with this, the above example can be constructed like this:
The above script is directly available in the script editor: Go to the "Documentation" tab and select "COM Automation" under the "Insert Example Script" submenu.

FastTrack COM syntax

As you may have noticed in the previous sections, working with the items under the editor's "COM Automation" uses a very different syntax than all other items. This is because when you are using the COM Automation items, you are effectively programming without the benefits of compiling code, which is a good reason to stay away from COM when possible.

To provide the highest readability possible in your scripts, the COM Automation items work with a property, method and parameter syntax known from Object-Oriented Programming Languages: Methods and properties are used by using a dot notation on an object, while method parameters are insides parentheses. It's important to understand that any property or method is also an object in itself - which is all explained in more detail in the "Inline Initializers" section further down.

Let's look at the COM items:
You might be surprised that you only need these few items for any type of COM operation. This is because most of the COM complexities are resolved by the engine in order to simplify your scripting as much as possible when dealing with COM operations. For example, to get a value, you do not need to know when an object is a method or property. When you use the ObjectValue function to get the value of a property or the result of a method, it will automatically be determined for you at run-time, if the object is, in fact, a property or method. This is why there is only one "ObjectValue" function and not two "ObjectProperty" and "ObjectMethod" functions. Likewise, there is no distinction between CreateObject and GetObject, known from other scripting languages (see next section for details).

The CreateObject function

If you are familiar with VBScript or KiXtart, you will know that any COM operation will have to start with a CreateObject or GetObject command. CreateObject creates a COM object and GetObject connects to a running COM component. Sometimes it can be confusing to know when to use which, which is why FastTrack automatically resolves which to use at run-time. Therefore there is no GetObject function, as the CreateObject function will automatically detect the correct method of use behind the scenes. CreateObject will simply do both.

A function is normally used as [Function <Parameters>]. CreateObject is also a function, but it's the exception to this rule. Let's look at an example:
You might have expected to use it a SetObject MyExcel=[CreateObject Excel.Application]. The reason for this syntactical difference is because of the general object dot notation on COM objects. Let's look at CreateObject in another context: SetObject can be used with just the CreateObject function, as above, but anywhere CreateObject is used, any sub-object or sub-property can be retrieved instead, simply by dotting your way to the desired object. Below, an object is retrieved to a system folder object of the executing engine's parent folder. The second line displays the "Name" property of this object, which is the name of the parent folder. For simplicity, we will display results with the ShowMessage command in the examples from here on.

Looping through objects

Some methods can return a collection of objects. To loop through an object collection, use the ForEachObject looping construct. In the example below CreateObject connects to the WMI interface on the local computer and performs a WMI query to retrieve the Name property of each disk object from the Win32_LogicalDisk disk WMI collection.
Other properties than "Name" can then be used inside the loop on the "Drive" object. The most common use of COM is using WMI objects, as explained in this article and in the example above. For this reason there is also a CreateWMIObject function, which is basically the same as CreateObject, except that is assumes that the object is "winmgmts:" and the method is "ExecQuery". The above can therefore be written in this way also:

The SetObject command

All COM related commands, functions and the ForEachObject loop can use the CreateObject function. Any object set with SetObject can be used instead of CreateObject as the first parameter, if preferred. The result of any COM operation can be used as an object, meaning that the looping construct above could also be written as shown below, with the same result.
It's important to understand that every time CreateObject is used, a new instance of the object is created. Usually COM operations are relatively simple and do just one thing, in which case there is no need to use SetObject first. However, in our earlier Excel spreadsheet example, there had to be a single SetObject which was to be used in all other operations. If CreateObject was used in every script line, a new Excel spreadsheet would have been created every time, and the script would not work.

Inline initializers

In the previous sections, we have used dot notations multiple times. Let's look at how that actually works. FastTrack can automatically initialize and use objects in-line to an indefinite level, which can make your COM scripts much shorter than similar scripts created with other languages. Consider this example:
This is relatively straight-forward and similar to what you would see with other scripting languages. First an instance of Scripting.FileSystemObject is created. Then we need to call the method "GetDrive" to get an object on which we need the property named "FreeSpace". We don't really have any use for the "GetDrive" object itself in this example, so we can let FastTrack initialize it dynamically as part of retrieving the property like this:
...or, alternatively, as part of setting the object:
The above example will produce the same result because CreateObject can also be used as an in-line initializer itself. Anywhere you would use an object, you can dynamically initialize the root object by creating a COM object with the CreateObject function. This means our example can be written down to one single line without really losing readability:
Please note that this example is for demonstration purposes only; it could also be simply done by using the FreeDiskSpace function:

Type casting

The last thing about which you must be aware when using COM interfaces in any language, is that they are strongly typed. This means that the type of parameters must be explicit. Consider these three lines from the Excel example earlier on this page:
FastTrack will automatically convert parameters and values. In almost any case, the conversion is correct, which saves you the trouble of explicitly specifying types any time you use a value or parameter. However, in a special case, you could be forced to explicitly overrule the conversion and this can be done by "type casting" a value or parameter to String, Int, Boolean, Decimal, Double, DateTime, Byte or Char. If we look at the example lines above, the last two lines will be correctly converted to integer and boolean respectively. The first line, however, would have been converted to a Decimal value, but since we mean a cell-formatting string, we need to type cast it to a string, which is why the value is prefixed with the (string) type cast.

Advanced COM automation example 1: Getting Microsoft Office information from the Excel COM interface

This example will query the COM interface of Microsoft Excel for information like installed version, installation path and language. The information can then be used in a logon script for example to determine, if an upgrade is needed.

This example is also available in the script editor: Go to the "Documentation" tab and select "Get Office Install Info" under the "Insert Example Script" submenu.

Advanced COM automation example 2: Controlling Hyper-V machines with the COM interface and WMI

This example will list all Hyper-V machines on the local machine and control the state of the selected machine. With 5 virtual machines, the initial menu could look like this:



This example is also available in the script editor: Go to the "Documentation" tab and select "Hyper-V State Controller" under the "Insert Example Script" submenu.

Advanced COM automation example 3: ActiveX Data Objects

This example is an extract from the Interacting with SQL Server page, where ADO is used to retrieve data from SQL Server. In the example, data is read from a logon audit table with three columns: LogonID, UserName and LogonTime. The example loops through the returned records from the SQL statement using COM. For more information, please refer to the full article on the Interacting with SQL Server page.