automation error 1

[brew2]

When trying to use Microsoft Outlook in an app I get an 'Automation Error. The specified module could not be found' error. Here is the code:

Function SendOutlookMessage(ByVal sSubject As String, _
                ByVal sBody As String, ByVal sSendTo As String, _
                ByVal bShowOnly As Boolean, _
                Optional ByVal sAttachmentFileName As String = "") As Boolean
    
         
    Dim objOutlook As Outlook.Application
    Dim objOutlookMsg As Outlook.MailItem
    Dim objOutlookRecip As Outlook.Recipient
    Dim objOutlookAttach As Outlook.Attachment
       
      ' Create the Outlook session.
    Set objOutlook = New Outlook.Application 'this is where the error is created

end function

Any help would be appreciated. thanks.

 

[JoeAtWork]

Have you referenced the Outlook library?

And sorry but I have to ask, is Outlook installed on the machine?

 

[brew2]

yes to both.

 

[BobRodes]

This might be a little help: when it says Automation Error, that means that the error was raised inside Outlook when you tried to construct the Application object.

 

[brew2]

Does the version of Outlook matter? This vb app was working fine with office 2003.

 

[MakeItSo]

Hi Brew,

when you say "This vb app was working fine with office 2003.", are you simply reusing this code with 2007 now?

If so: make sure you do not have outlook doubel-referenced.
Check your VB project settings. Do you have a reference set for both, Outlook 11 library AND Outlook 12 lib?
That might cause the error.

P.S: Why Dim as Outlook.Application and then create a new application object?
You can have both in one breath:

[b]Dim outl As New Outlook.Application[/b]
Dim objOutlookMsg As Outlook.MailItem

Set objOutlookMsg = outl.CreateItem(olMailItem)
objOutlookMsg.Display

This little snippet worked fine on my machine.
I do however work with Outlook 2003.

Aaaaaaah: I think i got it!
====>Security settings!
I remember that I had to change security settings in Outlook before my first OL automation
With a fresh installation of 2007, your OL security settings are probably back to factory settings, i.e. do not allow automisation.

I couldn't find the respective article in MS knowledge base, but it surely is there somewhere.
Check it.

Perhaps the latest Office security patch might already solve the problem.

Cheers,
Andy


[blue]Help us, join us, participate
IAHRA - International Alliance of Human Rights Advocates[/blue]

 

[MakeItSo]

Found something.
Perhaps this will help:

http://www.mapilab.com/outlook/security/

Good luck!


[blue]Help us, join us, participate
IAHRA - International Alliance of Human Rights Advocates[/blue]

 

[MakeItSo]

Also check out these pages, dealing with the "Outlook Object Model Guard" and changes in code security from OL 2003 to OL 2007:

http://msdn2.microsoft.com/en-us/library/ms778202.aspx

[blue]Help us, join us, participate
IAHRA - International Alliance of Human Rights Advocates[/blue]

 

[HughLerwill]

You are using early binding, presumably with a Project reference into the OutLook version installed on the development machine. That may make your code/ final app version specific to the version of Outlook on the development machine.

Late binding should overcome such problems;

Private Sub Command1_Click()

Dim success As Boolean

success = SendOutlookMessage("MySubject", "MysBody", "MyContact", True)

MsgBox "It worked " & success

End Sub

Function SendOutlookMessage(ByVal sSubject As String, _
ByVal sBody As String, ByVal sSendTo As String, _
ByVal bShowOnly As Boolean, _
Optional ByVal sAttachmentFileName As String = "") As Boolean


Dim objOutlook As Object

On Error GoTo failed

' Create the Outlook session.
Set objOutlook = CreateObject("Outlook.Application")

With objOutlook
'etc

End With

SendOutlookMessage = True

failed:
Set objOutlook = Nothing

End Function

 

[brew2]

Thanks to all for their suggestions. Just un-installed 2007 and installed 2003. VB6 app works as it has before.

Next step is to install 2007 again and try some of the suggestions here.

Any ideas why it works with 2003 and not 2007?

Thanks.

 

[JoeAtWork]

I would go with HughLerwill's suggestion of using late binding.

 

[BobRodes]

I wouldn't.

 

[brew2]

Bob Rhodes, earlier you said 'that means that the error was raised inside Outlook when you tried to construct the Application object'. Does that mean that Outlook 2007 could be the culprit? and therefore, if I want 2007, i'll need both versions of outlook?

Thanks

 

[HughLerwill]

<<I wouldn't>>

So Bob tell us with early binding how else you can cater for versions of Outlook/ Excel/ Word other than the one you used for the project reference when the app was compiled.

 

[BobRodes]

<P.S: Why Dim as Outlook.Application and then create a new application object?
You can have both in one breath:

Makeitso, this is not best practice. See faq222-6008 for more information.

<So Bob tell us with early binding how else you can cater for versions of Outlook/ Excel/ Word other than the one you used for the project reference when the app was compiled.

Suppose instead that you show why you're willing to conclude that this significant overhead investment is necessary, given the information you had regarding the OP's problem domain at the time you drew the conclusion. (In all fairness, Hugh is correct that you have to use late binding in the situation he describes.)

<Does that mean that Outlook 2007 could be the culprit?
It's more likely that it's looking for settings or information that it doesn't have, and that you don't know you have to provide. I'm sorry, but I don't have specific expertise on the Outlook Application object. I'd be willing to bet, though, that MakeItSo is on the right track. I would read his post again.

 

[JoeAtWork]

Well brew2, perhaps you could tell us if the application needs to run in both Outlook 2003 and 2007 environments. That would solve the debate over using late binding or not.

If it's a permanent move to Outlook 2007, I would suggest it is a library referencing issue as MakeItSo has described. Make sure you are referencing the library for 2007, not 2003. And also as MakeItSo has suggested, it could be security (although one would hope that in such a case the error would be more like "security settings are to high to allow automisation" rather than the generic and meaningless "Automation error").

 

[HughLerwill]

The way I see it and it has worked for me for a long time;

1. If you use early binding with say Outlook v10.n on the development machine your app when compiled looks for an actual Outlook 10 object library when it runs on any machine. If it does'nt find an actual Outlook v10 object library it fails, a version 9 or a version 11 will not do.

2. If you use late binding your app will just look for any object library called 'Outlook.Application' and will pick one up, if it exists, regardless of its version number. In this case you must limit your code to that understood by the lowest version of the object library you wish to cater for or detect the version and branch appropriatley.

 

[BobRodes]

<In this case you must limit your code to that understood by the lowest version of the object library you wish to cater for or detect the version and branch appropriatley.

Right, and that's the more efficient way to go in terms of performance, sometimes significantly so. Of course, you may have situations in which development overhead outweighs performance overhead and in such a case it may well be that late binding makes sense, rather than going to the trouble you describe here. On the other hand, I wouldn't personally assume that the OP ought to go in for that inefficiency just because it's working for you, and I wouldn't make such a recommendation based on the very sketchy information I had at my disposal at the time you made it.

So, no, Hugh and Joe, I wouldn't go with late binding, at least not yet. I would first do my best to come up with an early binding solution.

Bob

 

[HughLerwill]

I'm confused Bob are you saying late or early binding is more efficient (faster). Theoretically I understand that early is the most efficient and faster however;

In my experience performance re early/ late binding may have been an issue when we used 200 Mhz single core processors but today the difference is just not worth considering. It seems clear that the most versatile/ compatible method should be employed, unless you want to write sub versions of the app for every version of Office ever, or yet to be, invented.

I do not have much experience with automating Outlook but an alternative if dealing with Excel would be to use an Template containing a macro to do what I required and call that macro from the VB6 code; the VBA macro environment is more forgiving in that it appears to just assume the version of the host application object it is being run under rather than the the one it was written under. It appears possible to write macros/ VBA projects in Outlook but I have not been there.

I'm done.

 

[MakeItSo]

@Bob: I wasn't aware of that "multiple check" issue with early binding!
Thanks a bunch, I will implement that in my projects as a performance enhancer!

[blue]Help us, join us, participate
IAHRA - International Alliance of Human Rights Advocates[/blue]