I Need MS Outlook Object Library 9.0

[S Jackson]

I am creating a database and part of its function is it will add records as
tasks to Outlook. My problem is that I am using MS Outlook Object Library
11.0. The other users have MS Outlook Object Library 9.0. How can I get
this library and add it as a reference to my database?

Thanks
S. Jackson

 

[Dan Artuso]

Hi,
Outlook Object Library 9.0 *is* Outlook.
If you don't have that version installed then you
can't reference it.

The trick is to use late binding, that way you don't set
a reference to any version of Outlook.

Here is a little snippet:

Dim olNameSpace As Object
Dim olFolders As Object
Dim olCalFolder As Object
Dim olApp As Object
Dim olItems As Object
Dim olAppItem As Object
Dim strText As String


Set olApp = CreateObject("Outlook.Application")

Set olNameSpace = olApp.GetNamespace("MAPI")

Set olCalFolder = olNameSpace.GetDefaultFolder(olFolderCalendar)
'these next two lines get a reference to my test calendar
Set olFolders = olNameSpace.Folders.Item("personal calendar")

Set olAppItem = olCalFolder.Items.Add(olAppointmentItem)


What I do is I set a reference for the initial development so I get the intelisense,
then I remove the reference, make sure everything is Dimmed as Object and use CreateObject when I'm done.

 

[Randy Harris]

Dan, are you saying that using the method you described below, I would then
never need the reference for the finished application? Would that then make
an MDE completely independent of the version of Outlook installed on the
client workstation?

Thanks in advance for helping out those of us still coming up to speed on
these technologies.

Hi,
Outlook Object Library 9.0 *is* Outlook.
If you don't have that version installed then you
can't reference it.

The trick is to use late binding, that way you don't set
a reference to any version of Outlook.

Here is a little snippet:

Dim olNameSpace As Object
Dim olFolders As Object
Dim olCalFolder As Object
Dim olApp As Object
Dim olItems As Object
Dim olAppItem As Object
Dim strText As String


Set olApp = CreateObject("Outlook.Application")

Set olNameSpace = olApp.GetNamespace("MAPI")

Set olCalFolder = olNameSpace.GetDefaultFolder(olFolderCalendar)
'these next two lines get a reference to my test calendar
Set olFolders = olNameSpace.Folders.Item("personal calendar")

Set olAppItem = olCalFolder.Items.Add(olAppointmentItem)


What I do is I set a reference for the initial development so I get the intelisense,
then I remove the reference, make sure everything is Dimmed as Object and

use CreateObject when I'm done.

 

[Van T. Dinh]

Sort of Yes.

You only need to be beware that the features from Outlook you used in your
code will be available from the Outlook versions that your users have.

The Outlook Object Library that you user has may not have the features you
used if he/she has a different version from the one you used in your design.
In this case, your user will get a run-time error.

 

[Dan Artuso]

Hi,
What Van said
Yes, you don't need to (in fact shouldn't) set a reference to
Outlook in the finished product which makes it totally independant
of the version installed on clients.

Unless you're writing for a very controlled environment it's
really the only way you should code an app that uses any of
the Office object libraries.

 

[Randy Harris]

Hi,
What Van said
Yes, you don't need to (in fact shouldn't) set a reference to
Outlook in the finished product which makes it totally independant
of the version installed on clients.

Unless you're writing for a very controlled environment it's
really the only way you should code an app that uses any of
the Office object libraries.

Can I assume that your comments (and Van's as well) would apply to a
reference to Excel as well as Outlook?

Thanks again.
Randy

 

[Douglas J. Steele]

Can I assume that your comments (and Van's as well) would apply to a
reference to Excel as well as Outlook?

Yup. It applies to (virtually) any application you might refer to.

 

[Randy Harris]

This thread has been something of an eye opener for me. I was blissfully
(and ignorantly) using the Outlook and Excel library references. I've
gotten the app to work without the Outlook library, Excel will be a bit of a
bigger job (used extensively with lots of XL constants).

If you don't mind, I have a couple more questions. Is eliminating the use
of the references (as suggested) the same thing as late binding? What
impact, if any, is this change likely to have on performance? What impact,
if any, is the change likely to have on the size of the final application
(MDE)?

Thanks, once again, for all of the help
Randy Harris

Dan, are you saying that using the method you described below, I would then
never need the reference for the finished application? Would that then make
an MDE completely independent of the version of Outlook installed on the
client workstation?

Thanks in advance for helping out those of us still coming up to speed on
these technologies.

Hi,
Outlook Object Library 9.0 *is* Outlook.
If you don't have that version installed then you
can't reference it.

The trick is to use late binding, that way you don't set
a reference to any version of Outlook.

Here is a little snippet:

Dim olNameSpace As Object
Dim olFolders As Object
Dim olCalFolder As Object
Dim olApp As Object
Dim olItems As Object
Dim olAppItem As Object
Dim strText As String


Set olApp = CreateObject("Outlook.Application")

Set olNameSpace = olApp.GetNamespace("MAPI")

Set olCalFolder = olNameSpace.GetDefaultFolder(olFolderCalendar)
'these next two lines get a reference to my test calendar
Set olFolders = olNameSpace.Folders.Item("personal calendar")

Set olAppItem = olCalFolder.Items.Add(olAppointmentItem)


What I do is I set a reference for the initial development so I get the intelisense,
then I remove the reference, make sure everything is Dimmed as Object

and
use CreateObject when I'm done.

 

[Douglas J. Steele]

Yes, late binding is nothing more than removing the references.

The literature normally talks that there is a performance hit, since Access
now has to do some searching to determine what object it is you want to
create, but realisitically that only occurs when you're instantiating the
objects: once they've been instantiated, there should be no difference in
performance. And given that the alternative is that the application isn't
going to work, I would think that taking a slight performance hit isn't that
much of a problem! <g>

It shouldn't have much effect on the size of the database. If you create a
bunch of global constants to replace the ones you lost when you remove the
reference, that may increase the size slightly.

--
Doug Steele, Microsoft Access MVP

(No private e-mails, please)

This thread has been something of an eye opener for me. I was blissfully
(and ignorantly) using the Outlook and Excel library references. I've
gotten the app to work without the Outlook library, Excel will be a bit of a
bigger job (used extensively with lots of XL constants).

If you don't mind, I have a couple more questions. Is eliminating the use
of the references (as suggested) the same thing as late binding? What
impact, if any, is this change likely to have on performance? What impact,
if any, is the change likely to have on the size of the final application
(MDE)?

Thanks, once again, for all of the help
Randy Harris

Dan, are you saying that using the method you described below, I would then
never need the reference for the finished application? Would that then make
an MDE completely independent of the version of Outlook installed on the
client workstation?

Thanks in advance for helping out those of us still coming up to speed on
these technologies.

Hi,
Outlook Object Library 9.0 *is* Outlook.
If you don't have that version installed then you
can't reference it.

The trick is to use late binding, that way you don't set
a reference to any version of Outlook.

Here is a little snippet:

Dim olNameSpace As Object
Dim olFolders As Object
Dim olCalFolder As Object
Dim olApp As Object
Dim olItems As Object
Dim olAppItem As Object
Dim strText As String


Set olApp = CreateObject("Outlook.Application")

Set olNameSpace = olApp.GetNamespace("MAPI")

Set olCalFolder = olNameSpace.GetDefaultFolder(olFolderCalendar)
'these next two lines get a reference to my test calendar
Set olFolders = olNameSpace.Folders.Item("personal calendar")

Set olAppItem = olCalFolder.Items.Add(olAppointmentItem)


What I do is I set a reference for the initial development so I get

the
intelisense,

then I remove the reference, make sure everything is Dimmed as Object

and
use CreateObject when I'm done.

 

[Randy Harris]

Yes, late binding is nothing more than removing the references.

The literature normally talks that there is a performance hit, since Access
now has to do some searching to determine what object it is you want to
create, but realisitically that only occurs when you're instantiating the
objects: once they've been instantiated, there should be no difference in
performance. And given that the alternative is that the application isn't
going to work, I would think that taking a slight performance hit isn't that
much of a problem! <g>

No argument there! As important as performance is, it pales next to
stability and reliability.

It shouldn't have much effect on the size of the database. If you create a
bunch of global constants to replace the ones you lost when you remove the
reference, that may increase the size slightly.

I thought that perhaps, using this method, Access would bind in the needed
library routines at compile time rather than depending on their availability
at run time. And, if it did, it could make the app bigger.

 

[Van T. Dinh]

The Libraries are not included in the database file, only
referenced. Thus, the database file should't change
substantially.

At run-time, Access calls the Libraries and the Libraries
are loaded in the memory but you will need the Libraries
in the memory with both early-binding and late-binding.

HTH
Van T. Dinh
MVP (Access)

 

[Randy Harris]

I guess I'm still confused. Sorry.

If late binding makes it unnecessary to have the client application
(Outlook, Excel, whatever) installed on the client system, how can it get
the libraries at run-time to load into memory? Are they included as part of
the Access run-time?

 

[Van T. Dinh]

(Note: If you automate, says, Outlook from Access, then Access is the
Automation Client and Outlook is the Automation Server since Outlook
"serves" Access in this case).

You still need the Automation Server applications (Outlook, Excel, ...)
installed on the PC to be able to use either early or late binding. In
early-binding, Access is "aware" of what types of objects they are at
Compile time. In late-binding, Access doesn't know what they are until the
execution of, says, the statement CreateObject or OpenObject. Either way,
you still need to have Outlook, Excel, etc ... installed (which includes the
Object Library) on the PC since Access will call these Libraries sooner or
later.

If you add a Reference into the References Collection (in early-binding),
you specify the VERSION of the Library. If you declare Objects as general
Objects (i.e. late-binding), you don't specify the version and hence, the PC
can use whichever version of the Object Library installed, provided that the
Objects you used exist in the installed version.

Thus, the advantage of the late-binding is that your Access application
should normally works with WHICHEVER version of the Automation Server
Library installed (proviso mentioned previously) while with early-binding,
the user's PC must have EXACTLY the same version of the Object Library as
the one you specified in the References. For example, if you use only basic
process in Outlook, late-binding enables you code to work with Outlook97 /
98 / 2K / XP while in early-binding, says, Outlook2K, you code will ONLY
work if the user has Outlook2K installed on his / her PC. If you specify
early-binding with, says Outlook2K and the user has any other Outlook, you
will have the Reference error and your code referring to any Outlook object
(normally the Outlook Application Object) will error out.