I was looking into creating prefilled emails using Outlook Automation earlier today and ran into an unexpected snag. The requirement was to display a pre-filled email that contains recipient, subject, body and one or more attachments and then display the prefilled email in Outlook.
This is fairly straightforward to do using COM Automation:
TRY *** NOTE: This fails if you run as Administrator (rather than the active user) loOutlook = GETOBJECT(,"Outlook.Application") CATCH ENDTRY IF VARTYPE(loOutlook) != "O" loOutlook = CREATEOBJECT("Outlook.Application") ENDIF IF VARTYPE(loOutlook) != "O" MESSAGEBOX("Couldn't create Outlook instance") RETURN ENDIF loItem = loOutlook.CreateItem(0) loItem.Body = "Hello World" loItem.Subject = "New Test Message" loItem.Recipients.Add("email@example.com") *** Add you files to attach here loItem.Attachments.Add("c:\sailbig.jpg") loItem.Display() RETURN
Note that Outlook – as most Office Applications – is a Singleton object that expects to run only one instance. So if Outlook is already running you can use CREATEOBJECT() to create a new instance. Instead, you have to attach to an already running instance using GETOBJECT().
Gotcha: Running as Administrator makes GETOBJECT() fail
I typically run FoxPro as an Administrator because I frequently build COM objects, which requires that you run as a full administrator in order to write COM registration to the registry.
However, when running the above code, it turns out the GETOBJECT() call to capture Outlook.Application fails. It works fine when you run as a non-admin user or even as an Admin user when User Account Control (UAC) is enabled on the machine and your account is effectively running as a non Admin account.
But when you explicitly run as an Administrator either using Run As Administrator when you start the app, or from ShortCut properties, or if you have UAC disabled on the machine, you'll find that the GETOBJECT() call fails with:
OLE error code 0x800401e3: Operation unavailable.
The reason for this is that when you run as Administrator you are actually running a different user account (Administrator – duh) and that account can't actually access the running instance of Outlook that is already running on your desktop. The only workaround I could find is to ensure both Outlook and your application run in the same execution context. So it works if you run your app without administrative rights, or if you run your app as administrator as well as Outlook.
As you might expect it took me a long time to figure out WTF was going on here. According to all examples I've seen Outlook should be accessible with GETOBJECT(). It wasn't until I tried using wwDotnetBridge and COM Interop doing the same thing with .NET and getting the same response in FoxPro but not in LinqPad when I realized it must have something to do with the actual runtime environment. Sure enough – once I started VFP without Run as Administrator option, the code works.