Suppose you're composing a document with Microsoft Word.
You want to include an Excel spreadsheet.
You could save the spreadsheet in some image format that Word can understand,
and import it into your document.
But if the spreadsheet changes,
your document will be out of date.

Microsoft's OLE (Object Linking and Embedding,
pronounced "olay") lets one program use objects from another.
In the above scenario,
the spreadsheet is the object.
As long as Excel makes that spreadsheet available as an OLE object,
and Word knows to treat it like one,
your document will always be current.

You can control OLE objects from Perl with the Win32::OLE module,
and that's what this article is about.
First,
I'll show you how to "think OLE," which mostly involves a lot of jargon.
Next,
I'll show you the mechanics involved in using Win32::OLE.
Then we'll go through a Perl program that uses OLE to manipulate Microsoft Excel,
Microsoft Access,
and Lotus Notes.
Finally,
I'll talk about Variants,
an internal OLE data type.

When an application makes an OLE object available for other applications to use,
that's called OLE automation.
The program using the object is called the controller,
and the application providing the object is called the server.
OLE automation is guided by the OLE Component Object Model (COM) which specifies how those objects must behave if they are to be used by other processes and machines.

There are two different types of OLE automation servers.
In-process servers are implemented as dynamic link libraries (DLLs) and run in the same process space as the controller.
Out-of-process servers are more interesting; they are standalone executables that exist as separate processes - possibly on a different computer.

The Win32::OLE module lets your Perl program act as an OLE controller.
It allows Perl to be used in place of other languages like Visual Basic or Java to control OLE objects.
This makes all OLE automation servers immediately available as Perl modules.

Don't confuse ActiveState OLE with Win32::OLE.
ActiveState OLE is completely different,
although future builds of ActiveState Perl (500 and up) will work with Win32::OLE.

Objects can expose OLE methods,
properties,
and events to the outside world.
Methods are functions that the controller can call to make the object do something; properties describe the state of the object; and events let the controller know about external events affecting the object,
such as the user clicking on a button.
Since events involve asynchronous communication with their objects,
they require either threads or an event loop.
They are not yet supported by the Win32::OLE module,
and for the same reason ActiveX controls (OCXs) are currently unsupported as well.

The Win32::OLE module doesn't let your Perl program create OLE objects.
What it does do is let your Perl program act like a remote control for other applications-it lets your program be an OLE controller.
You can take an OLE object from another application (Access,
Notes,
Excel,
or anything else that speaks OLE) and invoke its methods or manipulate its properties.

First,
we need to create a Perl object to represent the OLE server.
This is a weird idea; what it amounts to is that if we want to control OLE objects produced by,
say,
Excel,
we have to create a Perl object that represents Excel.
So even though our program is an OLE controller,
it'll contain objects that represent OLE servers.

You can create a new OLE server object with Win32::OLE->new.
This takes a program ID (a human readable string like 'Speech.VoiceText') and returns a server object:

my $server = Win32::OLE->new('Excel.Application', 'Quit');

Some server objects (particularly those for Microsoft Office applications) don't automatically terminate when your program no longer needs them. They need some kind of Quit method, and that's just what our second argument is. It can be either a code reference or a method name to be invoked when the object is destroyed. This lets you ensure that objects will be properly cleaned up even when the Perl program dies abnormally.

To access a server object on a different computer, replace the first argument with a reference to a list of the server name and program ID:

You can also directly attach your program to an already running OLE server:

my $server = Win32::OLE->GetActiveObject('Excel.Application');

This fails (returning undef) if no server exists, or if the server refuses the connection for some reason. It is also possible to use a persistent object moniker (usually a filename) to start the associated server and load the object into memory:

Once you've created one of these server objects, you need to call its methods to make the OLE objects sing and dance. OLE methods are invoked just like normal Perl object methods:

$server->Foo(@Arguments);

This is a Perl method call - but it also triggers an OLE method call in the object. After your program executes this statement, the $server object will execute its Foo() method. The available methods are typically documented in the application's object model.

Parameters. By default, all parameters are positional (e.g. foo($first, $second, $third)) rather than named (e.g. foo(-name => "Yogi", -title => "Coach")). The required parameters come first, followed by the optional parameters; if you need to provide a dummy value for an optional parameter, use undef.

Positional parameters get cumbersome if a method takes a lot of them. You can use named arguments instead if you go to a little extra trouble - when the last argument is a reference to a hash, the key/value pairs of the hash are treated as named parameters:

$server->Foo($Pos1, $Pos2, {Name1 => $Value1,
Name2 => $Value2});

Foreign Languages and Default Methods. Sometimes OLE servers use method and property names that are specific to a non-English locale. That means they might have non-ASCII characters, which aren't allowed in Perl variable names. In German, you might see Öffnen used instead of Open. In these cases, you can use the Invoke() method:

$server->Invoke('Öffnen', @Arguments);

This is necessary because $Server->Öffnen(@Arguments) is a syntax error in current versions of Perl.

As I said earlier, objects can expose three things to the outside world: methods, properties, and events. We've covered methods, and Win32::OLE can't handle events. That leaves properties. But as it turns out, properties and events are largely interchangeable. Most methods have corresponding properties, and vice versa.

An object's properties can be accessed with a hash reference:

$server->{Bar} = $value;
$value = $server->{Bar};

This example sets and queries the value of the property named Bar. You could also have called the object's Bar() method to achieve the same effect:

$value = $server->Bar;

However, you can't write the first line as $server->Bar = $value, because you can't assign to the return value of a method call. In Visual Basic, OLE automation distinguishes between assigning the name of an object and assigning its value:

Set Object = OtherObject
Let Value = Object

The Set statement shown here makes Object refer to the same object as OtherObject. The Let statement copies the value instead. (The value of an OLE object is what you get when you call the object's default method.

In Perl, saying $server1 = $server2 always creates another reference, just like the Set in Visual Basic. If you want to assign the value instead, use the valof() function:

Let's look at how all of this might be used. In Listing: 1 you'll see T-Bond.pl, a program that uses Win32::OLE for an almost-real world application.

The developer of this application, Mary Lynch, is a financial futures broker. Every afternoon, she connects to the Chicago Board of Trade (CBoT) web site at http://www.cbot.com and collects the time and sales information for U.S. T-bond futures. She wants her program to create a chart that depicts the data in 15-minute intervals, and then she wants to record the data in a database for later analysis. Then she wants her program to send mail to her clients.

Mary's program will use Microsoft Access as a database, Microsoft Excel to produce the chart, and Lotus Notes to send the mail. It will all be controlled from a single Perl program using OLE automation. In this section, we'll go through T-Bond. pl step by step so you can see how Win32::OLE lets you control these applications.

However, Mary first needs to amass the raw T-bond data by having her Perl program automatically download and parse a web page. That's the perfect job for LWP, the libwww-perl bundle available on the CPAN. LWP has nothing to do with OLE. But this is a real-world application, and it's just what Mary needs to download her data from the Chicago Board of Trade.

Mary wants to condense the ticker data into 15 minute bars. She's interested only in lines that look like this:

03/12/1998 US 98Mar 12116 15:28:34 Open

A regular expression can be used to determine whether a line looks like this. If it does, the regex can split it up into individual fields. The price quoted above, 12116, really means 121 16/32, and needs to be converted to 121.5. The data is then condensed into 15 minute intervals and only the first, last, highest, and lowest price during each interval are kept. The time series is stored in the array @Bars. Each entry in @Bars is a reference to a list of 5 elements: Time, Open, High, Low, and Close.

Now that Mary has her T-bond quotes, she's ready to use Win32::OLE to store them into a Microsoft Access database. This has the advantage that she can copy the database to her lap-top and work with it on her long New York commute. She's able to create an Access database as follows:

This uses Win32::ODBC (described in TPJ #9) to remove and create T-Bonds.mdb. This lets Mary use the same script on her workstation and on her laptop even when the database is stored in different locations on each. The program also uses Win32::OLE to make Microsoft Access create an empty database.

Every OLE server has some constants that your Perl program will need to use, made accessible by the Win32::OLE::Const module. For instance, to grab the Excel constants, say use Win32::OLE::Const 'Microsoft Excel'.

In the above example, we imported the Data Access Object con-stants just so we could use dbLangGeneral.

Here, Mary sets the locale to American English, which lets her do things like use American date formats (e.g. "12-30-98" rather than "30-12-98") in her program. It will continue to work even when she's visiting one of her international customers and has to run this program on their computers.

The value of $Win32::OLE::Warn determines what happens when an OLE error occurs. If it's 0, the error is ignored. If it's 2, or if it's 1 and the script is running under -w, the Win32::OLE module invokes Carp::carp(). If $Win32::OLE::Warn is set to 3, Carp::croak() is invoked and the program dies immediately.

Now the data can be put into an Excel spreadsheet to produce the chart. The following section of the program launches Excel and creates a new workbook with a single worksheet. It puts the column titles ('Time', 'Open', 'High', 'Low', and 'Close') in a bold font on the first row of the sheet. The first column displays the timestamp in hh:mm format; the next four display prices.

The last statement shows how to pass arrays to OLE objects. The Win32::OLE module automatically translates each array reference to a SAFEARRAY, the internal OLE array data type. This translation first determines the maximum nesting level used by the Perl array, and then creates a SAFEARRAY of the same dimension. The @Bars array already contains the data in the correct form for the spreadsheet:

We can change the type of the chart from a separate sheet to a chart object on the spreadsheet page with the $Chart->Location method. (This invalidates the chart object handle, which might be considered a bug in Excel.) Fortunately, this new chart is still the 'active' chart, so an object handle to it can be reclaimed simply by asking Excel.

At this point, our chart still needs a title, the legend is meaningless, and the axis has decimals instead of fractions. We can fix those with the following code:

The $High and $Low for the day are needed to determine the minimum and maximum scaling levels. MIN and MAX are spreadsheet functions, and aren't automatically available as methods. However, Excel provides an Evaluate() method to calculate arbitrary spreadsheet functions, so we can use that.

We want the chart to show major gridlines at every fourth tick and minor gridlines at every second tick. The minimum and maximum are chosen to be whatever multiples of 1/16 we need to do that.

Now the finished workbook can be saved to disk as i:\tmp\tpj\data.xls. That file most likely still exists from when the program ran yesterday, so we'll remove it. (Otherwise, Excel would pop up a dialog with a warning, because the SaveAs() method doesn't like to overwrite files.)

Mary stores the daily prices in her T-bonds database, keeping the data for the different contracts in separate tables. After creating an ADO (ActiveX Data Object) connection to the database, she tries to connect a record set to the table for the current contract. If this fails, she assumes that the table doesn't exists yet and tries to create it:

$Win32::OLE::Warn is temporarily set to zero, so that if $Recordset-Open> fails, the failure will be recorded silently without terminating the program. Win32::OLE-LastError> shows whether the Open failed or not. LastError returns the OLE error code in a numeric context and the OLE error message in a string context, just like Perl's $! variable.

Mary uses the Win32::OLE::Variant module to store $Day as a date instead of a mere string. She wants to make sure that it's stored as an American-style date, so in the third line shown here she sets the locale ID of the Win32::OLE::Variant module to match the Win32::OLE module. ($Win32::OLE::LCID had been set earlier to English, since that's what the Chicago Board of Trade uses.)

The program expects to be able to add a new record to the table. It fails if a record for this date already exists, because the Day field is the primary index and therefore must be unique. If an error occurs, the update operation started by AddNew() must first be cancelled with $Recordset->CancelUpdate; otherwise the record set won't close.

Now Mary can use Lotus Notes to mail updates to all her customers interested in the T-bond data. (Lotus Notes doesn't provide its constants in the OLE type library, so Mary had to determine them by playing around with LotusScript.) The actual task is quite simple: A Notes session must be started, the mail database must be opened and the mail message must be created. The body of the message is created as a rich text field, which lets her mix formatted text with object attachments.

In her program, Mary extracts the email addresses from her customer database and sends separate message to each. Here, we've simplified it somewhat.

In this final section, I'll talk about Variants, which are the data types that you use to talk to OLE objects. We talked about this line earlier:

my $Values = [Variant(VT_DATE, $Day),
$Open, $High, $Low, $Close];

Here, the Variant() function creates a Variant object, of type VT_DATE and with the value $Day. Variants are similar in many ways to Perl scalars. Arguments to OLE methods are transparently converted from their internal Perl representation to Variants and back again by the Win32::OLE module.

OLE automation uses a generic VARIANT data type to pass parameters. This data type contains type information in addition to the actual data value. Only the following data types are valid for OLE automation:

What if your Perl value is a list of lists? Those can be irregularly shaped in Perl; that is, the subsidiary lists needn't have the same number of elements. In this case, the structure will be converted to a "rectangular" SAFEARRAY of Variants, with unused slots set to VT_EMPTY. Consider this Perl 2-D array:

The Win32::OLE::Variant module. This module provides access to the Variant data type, which gives you more control over how these arguments to OLE methods are encoded. (This is rarely necessary if you have a good grasp of the default conversion rules.) A Variant object can be created with the Win32::OLE::Variant->new method or the equivalent Variant() function:

Several methods let you inspect and manipulate Variant objects: The Type() and Value() methods return the variant type and value; the As() method returns the value after converting it to a different variant type; ChangeType() coerces the Variant into a different type; and Unicode() returns the value of a Variant object as an object of the Unicode::String class.

These conversions are more interesting if they can be applied directly to the return value of an OLE method call without first mutilating the value with default conversions. This is possible with the following trick:

Normally, you wouldn't call Dispatch() directly; it's executed implicitly by either AUTOLOAD() or Invoke(). If Dispatch() realizes that the return value is already a Win32::OLE::Variant object, the return value is not translated into a Perl representation but rather copied verbatim into the Variant object.

Whenever a Win32::OLE::Variant object is used in a numeric or string context it is automatically converted into the corresponding format.

For methods that modify their arguments, you need to use the VT_BYREF flag. This lets you create number and string Variants that can be modified by OLE methods. Here, Corel's GetSize() method takes two integers and stores the x and y dimensions in them:

More information about the OLE modules can be found in the documentation bundled with Win32::OLE. The distribution also contains other code samples.

The object model for Microsoft Office applications can be found in the Visual Basic Reference for Microsoft Access, Excel, Word, or PowerPoint. These help files are not installed by default, but they can be added later by rerunning setup.exe and choosing custom setup. The object model for Microsoft Outlook can be found on the Microsoft Office Developer Forum at: http://www.microsoft.com/OutlookDev/.