[Use your browser's BACK button to return to the PRIME FAQ Page or click here if you came directly to this page.]

(Code) How to Pass Arguments to, and Get Return Values from, Custom WordBasic Procedures Using OLE Automation

This was taken from the PRIME Information electronic newsletter Issue 2. Follow-up to material published in our book The Underground Guide to Microsoft Office, OLE, and VBA (Addison-Wesley).

Click here to order The Underground Guide to Microsoft Office, OLE, and VBA from Amazon.

With a heading like that, you know you're in for some, ahem, interesting times up ahead.

In Word 6 and Word 7, the "Word.Basic" OLE Automation object allows you to directly retrieve values from built-in functions called from an OLE Automation client. Word.Basic allows you to directly pass arguments to built-in commands (effectively built-in subroutines) from an OLE Automation client. But it doesn't currently allow you to directly retrieve values from custom functions. And it doesn't currently allow you to directly pass arguments of any kind to custom subroutines or functions. So, you can manipulate the built-in Word commands, but if you want to work with any procedures you have written yourself you run head-first into problems. But there are ways around these obstacles, and therein lies the tale.

First let's review what can be done.

We'll deal with Excel as the client and use the special NORMAL.DOT template as the storage location for our test procedures. Why use NORMAL.DOT? Good question. Because it's always loaded in memory, so any procedure library in it is always available to an OLE Automation client, even if there are no other global templates loaded. Let's use a procedure library called MacroLib.

Another important consideration throughout this article is that for all the code presented here, we assume Word is already running. If Word is not already running, the client's code must sometimes deal with getting the focus back from Word once it has been started. This is relatively easy: (1) capture Excel's title bar before starting Word, and (2) force the focus back to Excel at the appropriate time. (See The Underground Guide to Microsoft Office, OLE, and VBA pages 301-302 for a general-purpose custom function called fstrGetHostTitleBar() to do just that.) But we wanted to keep the article's sample code uncluttered and have it execute quickly. So remember, have Word running before using this sample code.

This article is so large (30+ pages) that we provide it in its entirety as a downloadable file.
PRIME2.ZIP, self-extracting, 206,302 bytes.

For your convenience, here’s the article’s table of contents.

• AppActivate Ain't Always AppActivate
• Setting up a Test Workbook or Project to Run this Article's Code
• Calling a Built-in Numeric Function
• Calling a Built-in String Function
• Calling a Built-in Command with No Arguments
• Calling a Built-in Command with Arguments
• Calling a Built-in Command with One Argument That is Not an Array
• Utilities for Examining Type Libraries
• Calling a Built-in Command with Multiple Arguments, None of Which are Arrays
• Calling a Built-in Command with One Array Argument
• Calling Built-in Dialog Commands
• Displaying Built-in Dialogs
• Calling a Custom Function with More Than One Argument, None of Which are Arrays
• An OLE Automation Replacement for DDEPoke'ing a Word Bookmark
• Considerations When Visual Basic 3 is the Client

The Naked PC Subscribe to our free electronic newsletter. Get the latest on all things PC, updates to PRIME Freeware page, and more. Type your email name and click Subscribe.