Rob Eberhardt

I've been fighting with Outlook development again lately, custom form development in particular.  OL development is quirky, but there's one circumstance where it's downright bug-ridden: Custom Outlook forms using Windows' standard Common Dialog control.

The issues are numerous, but I'll list them as I've found them:

"The control could not be created because it is not properly licensed".

That link is to a thread in which Sue Mosher herself participates regarding her book's suggestion to use the Common Dialog on Outlook forms.  A reader discovered licensing issues with this, and Sue confesses "I think we didn't get it right, alas". 

Kudos to her for that.  But there is a workaround: when I ran into the same issue several months ago, I found (can't remember where right now, but I'll update if I do) that, due to the Common Dialog's (annoyingly dumb!) licensing, there's a right way to use it and a wrong way.  Basically, if you programmatically create the control object, licensing restrictions kick in, and it will only work on machines with MS developer tools installed.  However, if you drag/drop the control onto the form, you can programmatically use it without a hitch. 

So, drag/drop the control and code to it, instead of using code like CreateObject("MSComDlg.CommonDialog"), and you should be good.

VBScript's Native Error Handling is Broken

(Some?) Runtime VBScript Errors on Custom Outlook forms are suppressed.  Even with On Error Goto 0 explicitly set (which is the default in VBScript anyway), certain object-related errors are simply never raised. 

In particular, I was never actually getting the "The control could not be created because it is not properly licensed" error when I ran into it on users' machines (who didn't have MS dev tools installed).  Instead, that code was simply never running (as if I had On Error Resume Next set).  The only way I could track it down was by moving the code into a Windows Script, where native VBScript error handling does work:

Drag/Dropped Common Dialog Controls Become Invisible When Reopening a Custom Form

If you drag/drop a Common Dialog onto the form, it shows as a placeholder icon.  Save and the form template, reopen the template, and that placeholder icon is gone. 

I did determine that the Common Dialog is actually still there though.  I simply wrote some code which uses the control -- when I reopen, that code still finds and uses the invisible control without issue.  Pretty confusing to anyone who doesn't know/remember it's there, though!

Custom Field Data + Common Dialogs Cause Security Warnings

Outlook 2002 SP3 and Outlook 2003 have a security feature which restricts ActiveX controls on one-off forms.  Basically, if you open a form template or one-off form which contains an ActiveX control, OL blocks the control and gives this error:

The solution to this problem is to not use one-off forms, and to instead publish them.

Unfortunately, this is not that issue, but it's a somehow related OL bug.  What I found is that:
With items created from published custom form, which possess both custom fields and a Common Dialog control, if you save data in one of the custom fields, then you will get that error dialog on future openings of the item.

So another way of putting it:

• I publish my custom form (with custom fields & Common Dialog). 
• I can create a new item with it.  No problem.
• I can even save standard field data in it.  No problem (reopening is flawless).
• But as soon as I save data in a custom field and close, I get that dialog, and most of the form data is missing.

It's also a showstopper for me -- I painstakingly worked around the myriad other Common Dialog issues, but I gotta open a file and have custom data on my form.  So now I'm looking into other controls.  Hopefully Sue was right in suggesting Word's file dialog.  I don't like the external dependency, but I've checked and it appears I can do that (this time).  OR, there's also Windows' native Shell.Application object's BrowseForFolder method (which apparently has its own quirks).

For those considering embarking on the Common Dialog route, I'd recommend against it.  There are lots of alternatives.  I'll post my results with those later.

Update:

• The Word route didn't pan out -- 10 seconds to load the Word exe is way too slow for a file dialog.
• I also tried Shell.Application's BrowseForFolder method.  It's a bit clunky, though, and way too quirky.
• I think I've settled on a different common dialog: UserAccounts.CommonDialog, which is nearly identical to MSComDlg.CommonDialog.  Differences:
  • No licensing headaches
  • No OL security warnings
  • It requires Windows XP
  • "InitDir" property is renamed "InitialDir"
  ...Not bad at all.  Still nice & snappy, with WinXP as the only requirement (certainly palatable for me).