Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Office Server Quirks : Page 3

Automating the Office servers seems straightforward at first. But there are subtle (and not-so-subtle) differences in how they work that can trap unsuspecting developers.


advertisement
The Role of Templates
All three servers offer templates as a way to set up formatting and other features of a document. However, templates behave a little differently in each of the applications. Although the exact content of a template varies with the application, the primary features that go into a template are boilerplate contents, formatting and styles, and macros.
When you create a new document based on a specified template, Excel and PowerPoint simply make a copy of the template, while Word copies the boilerplate and formatting, but creates a connection to the template's macros.
When you're creating a new document based on a specified template, Excel and PowerPoint simply make a copy of the template, while Word copies the boilerplate and formatting, but creates a connection to the template's macros, and optionally, to its styles. What this means in practice is that changing the code in a Word macro stored in a template can affect the documents based on that template. That's not the case for PowerPoint and Excel.

The other big difference is the mechanism for creating new templates. Word gives you two opportunities to create a new template. You can specify that the document you're creating is a template in the Add method by passing True for the optional second parameter. You can also turn a document into a template by specifying the format wdFormatTemplate (1) as the second parameter to the SaveAs method. In Excel, you specify that a workbook is a template by passing xlTemplate (17) as the second parameter to SaveAs. Similarly, in PowerPoint, you create a template by passing ppSaveAsTemplate (5) as the second parameter to SaveAs.

Using Add-ins
Word, Excel, and PowerPoint all support add-ins, which are extensions to their core functionality. However, there are some differences, both in how you install add-ins, and in what happens when you do. In general, an add-in needs to be both registered and loaded in order to be available. All three applications have an AddIns collection, and each of the collections has an Add method with the filename of the add-in as the first parameter. However, at this point the three applications part company.



Word's AddIns.Add method lets you both register and load the add-in at once. By default, calling the Add method loads the add-in. If you want to register it without loading it, pass False for the second, optional, parameter to Add. To unload the add-in set the Installed property of the relevant AddIn object to False. In PowerPoint the Add method registers the add-in, then you must set the AddIn's Loaded property to True to make it available.

While you can register an add-in in Excel using the Add method of the AddIns collection (when there's an open workbook) and load it by setting the Installed property to True, Excel remembers the add-in the next time it's opened, but doesn't load it properly. There's another approach that gives better results. Excel lets you register and load an add-in in one step using the Workbooks.Open method, which loads the add-in for this instance but it doesn't carry over to future executions. In addition to the variations in how to get an add-in loaded, there's also a subtle difference in how add-ins behave while they're loading. Each of the servers supports a method that fires some code at the time the add-in is loaded. The exact name of this method varies with the application: Word calls it AutoExec, while Excel and PowerPoint call it Auto_Open. More important than the name of the method, though, is that Word's AutoExec method doesn't fire when Word is running as an Automation server, but only when Word was started interactively. This means that you can't count on code in the AutoExec method of an add-in to run when you use Word via Automation, or when you load an add-in in an automated Word instance.

To sum up, despite the fact that Office is a product suite, there are many differences between the various servers. The differences mean that you can't just write Automation code that works with one of the servers and assume it'll work with the others. This article should get you past some of the issues you're most likely to run into, but expect to find others as your Automation code gets more complex. (See sidebar: Speeding up Automation)



Tamar E. Granor, Ph.D. , has developed and enhanced numerous FoxPro and Visual FoxPro applications. She currently focuses on working with other developers through mentoring and subcontracting. Tamar served as Editor of FoxPro Advisor magazine from 1994 to 2000. She is currently the magazine's Technical Editor and co-author of the popular Advisor Answers column. Tamar is co-author of the Hacker's Guide to Visual FoxPro 7.0 (and its award-winning predecessor), What's New in Visual FoxPro 7.0, and Microsoft Office Automation with Visual FoxPro. She is the Technical Editor of Visual FoxPro Certification Exams Study Guide. Her books are available from Hentzenwerke Publishing (www.hentzenwerke.com). Tamar is a Microsoft Certified Professional and a Microsoft Support Most Valuable Professional. She speaks frequently about Visual FoxPro at conferences and user groups, including every FoxPro DevCon since 1993. She served as Technical Content Manager for the 1997-1999 Visual FoxPro DevCons and was part of the coordination team for the Visual FoxPro Excellence Awards. Reach her at Tamar@thegranors.com.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date