Outlook automation from VFP. Checking that Outlook is available

[AndrewMozley]

There is a VFP application that creates an Outlook object, intending to send an email. The broad sequence of instructions is :

#DEFINE MAILITEM 0
oOutlook = CreateObject(“Outlook.application”)
. . .
oEmailitem = oOutlook.CreateItem(MAILITEM)
. . .
oRecipients = oEmailItem.Recipients
. . .

On a workstation with Outlook configured and running, this works fine. On a workstation which does not have Outlook properly configured, the CreateObject() instruction sometimes fires up the Outlook installation processs, and sometimes it just continues until it fails at the oRecipients instruction.

I would like to detect this situation and warn the user before trying to create an email. To that end the program is checking the values of TYPE(‘oOutlook’) and Type(‘ oEmailitem’).

But they are returning ‘O’ (Object), even though the oRecipients instruction subsequently fails.

How can I test that Outlook is properly configured so that I can warn the user if it is not.

Thank you.

 

[TamarGranor]

Check also that the variables are not null. Also, check the oNS variable that you should also be creating:

oNS = oOutlook.GetNameSpace("MAPI")

Tamar

 

[AndrewMozley]

Thanks Tamar for your prompt reply; have found ‘Microsoft Office Automation with VFP’ a great help. I have modified my test program to include these diagnostics :

#DEFINE MAILITEM 0
WITH Thisform
   oOutLook = CreateObject("Outlook.Application")
   MESSAGEBOX("TYPE(oOutlook) = " + TYPE('oOutlook') + CHR(13) + ;
         "IsNull(oOutlook) = " + IIF(ISNULL(oOutlook), ".T.", ".F."))
   oNS = oOutlook.GetNameSpace("MAPI")
   MESSAGEBOX("TYPE(oNS) = " + TYPE('oNS') + CHR(13) + ;
         "IsNull(oNS) = " + IIF(ISNULL(oNS), ".T.", ".F."))

   oEmailItem = oOutLook.CreateItem(MAILITEM)
   MESSAGEBOX("TYPE(oEmailitem) = " + TYPE('oEmailitem') + CHR(13) + ;
         "IsNull(oEmailitem) = " + IIF(ISNULL(oEmailitem), ".T.", ".F."))
   oRecipients = oEmailitem.Recipients

However, I am finding that on the ‘CreateObject’ command this program fails the first time I run this; the Outlook installation process is fired up and I get a 1426 error.

The second time, within a reasonable space of time (may be installation dependent), all the three statements work (well, there is no error); and each of the Messagebox() calls return ‘O’ (object) and .the IsNull() calls return .F. But the program then causes error 1426 when I try the :

      oRecipients = oEmailitem.Recipients

I realise that I could put a TRY . . CATCH Sequence round this last instruction, but I still hope to find an interesting variable or function that I can test.

Thanks again for the time you have spent on this.

 

[Olaf Doschke]

I think handling that specific broken case of CREATEOBJECT firing up an installation process should not be solved by handling any error or checking some registry entries before even trying to create the Outlook.Application. This problem has to be solved on the levl of the Outlook installation.

Your only job is to check whether Outlook is installed or not. The only thing you'd do, if you'd be able to catch that error is give the user a more meaningful message, that they should care about their Outlook installation. This process of Office installation starting up already proves there is something wrong with the Office installation, that needs repair. I just share your pain users see this coming from your application always ask you to fi it.

It's quite impossible to detect whether that installation is started without doing CREATEOBJECT. Even putting it in TRY..CATCH this installation window will appear before the CATCH blcok is then triggered by a raised error. At a customer, where the existence of an Outlook installation is not available in Terminal Server Clients, I precheck this with a .NET EXE used as startup and handling many config and prerequisite checks and also update, but this also only checks, whether the OLE Class is registered and would also tell "yes". If Outlook is not at all installed the CREATEOBJECT will raise an immediate error and that should be handled in a TRY..CATCH statement.

Bye, Olaf.

 

[JackTheC]

By the way, you can send emails without Outlook. Like with
loConfig = CREATEOBJECT("CDO.Configuration") etc.

 

[Mike Lewis]

Andrew,

If the CREATEOBJECT() causes the Outlook installation routine to fire up, I would say that's not an error. If your application requires Outlook to be installed, and the user (or their IT department) has elected to "install on first use", then your application is behaving correctly.

I can understand that, in those circumstance, you would prefer to issue a friendly message which explains the situation. But you would presumably still need them to proceed with the installation routine, so the behaviour that you are seeing might be the best approach.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Mike,

I don't think that is the situation. I experienced such installation routine firing up on software already installed in many cases, just lately even with VFP itself, which was just installed the same date. You have such quirks with the Windows Installer system sometimes, and I faintly remember there was some steps to do, if not simply reinstall.

It is well known described as "Configuration Progress every time", which can happen every time you start a XLS(X) file or automate outlook or at other trigger events. eg like this:

Solutions vary from editing registry entries to renaming a setup.exe in program files to setupold.exe

Bye, Olaf.

 

[Mike Lewis]

I don't think that is the situation. I experienced such installation routine firing up on software already installed in many cases,

Now you mention it, Olaf, I've seen the same thing myself - a long time ago. I'll see if I can find the code that caused it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

The only cause for it I think is some configuration process never finishes or manages to store some information about being done with it and so it repeats endless, if you trigger certain events. Maybe even a file redirection or registry redirection UAC effect. But the code generating a mail is not the suspect here. The problem lies in the Office installation.

Bye, Olaf.

 

[Mike Lewis]

I've just discovered where I've seen this behaviour before. In fact, I posted a question about it here in Tek Tips. This was about ten years ago, but the answer should still be relevanat.

The post in question was in thread184-1321491.

This is the solution, received from Doug Hennig:

This problem is caused because of something Windows Installer does to the Registry entry for ActiveX controls: it changes the InprocServer32 entry to point to Windows Installer rather than the OCX file. When you install your application after Office (or vice versa) and run it, Windows calls the InprocServer32 entry when it instantiates the ActiveX control, which calls Windows Installer, which sees that the version of the OCX you've installed is different than what was originally installed, so it thinks the file is corrupted and prompts you to insert the CD so it can "repair" it.

The solution is to hack the Registry and change the InprocServer32 entry to the path and filename for the OCX. That way, it'll call the OCX rather than Windows Installer. In this case, the key is HKEY_CLASSES_ROOT\CLSID\{C74190B6-8589-11D1-B16A-00C0F0283628}\InprocServer32 and the filename is C:\Windows\System32\MSComCtl.OCX.

I followed Doug's advice, and it solved the problem for me. I'm not sure if this would be applicable to Andrew's problem, as he is using COM Automation rather than an ActiveX control, but the same general principle probably applies.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[AndrewMozley]

Thank you all.

My understanding is now that there are three cases.

1. If Outlook is properly installed, CreateObject() will return an Object, and you can then press on with CreateItem(), add recipients &c and in due course send the email.

2. If Outlook is not available at all (so perhaps no version of Office is available on the machine), CreateObject() will not return an object, so you can test that and give a suitable error message. However I have not been able to test this - I don’t have a machine which doesn’t have Office available, in some form

3. If Outlook is available on the machine, but not properly installed, (this is the case which I originally observed) the Outlook installation process is started up - you can see it on the screen - but as far as VFP is concerned, the CreateObject() happily returns an object. In this case all apparently works well until you try to refer to Recipients, when an error is raised.

I plan to cope with this by CATCHing the error and reporting back to the user; so that the VFP application is kept tidy. It is true that the Outlook installation process will have been started on the screen.

It may be that I could check for this last case by reading some item for the registry, but for the present I plan just to report the error.

And thank you JacktheC for mentioning CDO. Must admit I had never come across this; I will investigate

Again, thanks for all your work.

Andrew

 

[Olaf Doschke]

You've summarized this pretty good, yes. When you have the quirky situation I don't see a way to prevent that window about installation popping up. Providently reading the InprocServer32 node of the Outlook.Application registry key may not only be over the top, I don't think it'll cover all cases causing such repair installation popups anyway.

CDO also isn't avaiable everywhere, so I wouldn't rely on that. The most general use of mail will be by MAPI and you may then use the MapiSession and MAPIMessages OCX controls coming with VFP you are also allowed to redistribute - see

https://msdn.microsoft.com/en-us/library/aa733653(v=vs.60).aspx.

Also that is not standalone and roots in systems mapi dlls, which has problems with some windows versions and configurations, you find threads on this here, too.

Essentially it is much easier to use mail via Outloook Application once every client is correclty installed, so I'd also prefer it for projects done for a company having this as their company wide only mail client.

Besides that and MAPI you find lots of ways to send mails and it has beend posted everywhere, just search fox wikis, craig boyds blog, tek tips, msdn and any VFP forum. Mail is really a basic need, so it is covered in very many posts and blog/wiki articles.

https://www.sweetpotatosoftware.com/blog/?s=mail

http://fox.wikis.com/wc.dll?Wiki~AutomatedEmail~Wiki

Bye, Olaf.

 

[Mike Lewis]

I have not been able to test this - I don’t have a machine which doesn’t have Office available, in some form

On that particular point, you could try temporarily renaming the main Outlook executable. In that case, CREATEOBJECT() clearly won't return an object. That way, you could at least test that your own error-handling is correct.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Well, you don't get the typical "class not registtered" error massage, if the InprocServer32 registry entry still points to OUTLOOK.EXE and it is not there. You rather would remane the registry key of the Outlook.Application class to simulate outlook not installed.

A much simpler way to see what error happens is simulating that with o = CREATEOBJECT("Nonexisting.Application"), which has the same error as CREATEOBJECT("NonexistingClass"), Error 1733.

Bye, Olaf.

 

[atlopes]

I can help you with this:

2. If Outlook is not available at all (so perhaps no version of Office is available on the machine), CreateObject() will not return an object, so you can test that and give a suitable error message. However I have not been able to test this - I don’t have a machine which doesn’t have Office available, in some form

[tt]oOutLook = CreateObject("Outlook.Application")[/tt] raises the error 1733, and [tt]TYPE("m.oOutLook")[/tt] returns "U".

 

[AndrewMozley]

Thank you atlopes. So as well as testing the TYPE of the returned value, I would also need to CATCH that error.

 

[atlopes]

Yes, it is just a confirmation of what Olaf mentioned previously: TRY to CREATEOBJECT() and, if no errors were triggered, proceed to check the other scenarios.