by Mark Trescowthick - GUI Computing
I must admit, the prospect of Outlook including VBA was something I looked forward to... a halfway decent PIM (actually, in my opinion, better than that) with a scripting language I understood had a lot of appeal. Like many others, I fear, I've been disappointed by Outlook's scripting ability in this release. I guess it was a bit much to hope that we'd see VBA rather than VBScript, but I'm an optimist!
Still, I thought to myself, VBScript is better than nothing. I guess I wasn't exactly wrong there... it's just that I wasn't exactly right either. The main problem being, as I see it, that you can do virtually nothing to customise the Outlook interface using VBScript (or any other technique).
Even things as simple as replacing the standard email form with a new one aren't possible - nor is adding a new "standard" form to the "New" dropdown. Any new form you create can only be accessed via the Choose Form menu item. Which hardly makes for ease of use.
In fact, all the interesting / useful objects in what is a very limited object model seem to be read-only right now.
All that sounds pretty negative, but it's not to say that you can't do some pretty fancy footwork even so. Outlook's VBScript sports full data access ability, so, for example, you could set things up so that your Outlook Contacts were regularly updated to/from any ODBC data source. I found a treasure trove of this sort of thing at The Outlook Developer's Resource Center.
And, of course, the simple fact that Outlook exposes its object model means that you can get at it from Word, Excel or whatever - and conversely, that you can use it to get at them. That has some real possibilities.
If only I could give my users some easy way to find all this good stuff I can do - but until I can modify the interface easily, they're forced to stumble around in the interface searching. Cloudy indeed!