Dim objOutlook As Outlook.Application

[Ecapodieci]

Why is it whenever i an trying to declare variables such as...

Dim objOutlook As Outlook.Application

I get a "Compile Error" saying "User-defined type not defined. I specifically
got this from the following email code....


Private Sub Command0_Click()
'Arvin Meyer 03/12/1999
'Updated 7/21/2001
On Error GoTo Error_Handler

Dim objOutlook As Outlook.Application
Dim objEmail As Outlook.MailItem

Set objOutlook = CreateObject("Outlook.application")
Set objEmail = objOutlook.CreateItem(olMailItem)

With objEmail
.To = "(e-mail address removed)"
.Subject = "Look at this sample attachment"
.body = "The body doesn't matter, just the attachment"
.Attachments.Add "C:\Test.htm"
'.attachments.Add "c:\Path\to\the\next\file.txt"
.Send
'.ReadReceiptRequested
End With

Exit_Here:
Set objOutlook = Nothing
Exit Sub

Error_Handler:
MsgBox Err & ": " & Err.Description
Resume Exit_Here

End Sub


I see these types of declarations all over the place, but when i attempt to
use them, i get this error. It' spretty frustrating, but it's probably
something i should know.

 

[Dirk Goldgar]

Why is it whenever i an trying to declare variables such as...

Dim objOutlook As Outlook.Application

I get a "Compile Error" saying "User-defined type not defined.
[...]
I see these types of declarations all over the place, but when i
attempt to use them, i get this error. It' spretty frustrating, but
it's probably something i should know.

To use early binding (declaring as a specific object type, rather than
just as Object), you have to set a reference to the object library or
type library that defines the object. In this case, you'd need to click
Tools -> References... in the VB Editor, locate the Microsoft Outlook
<version> Object Library in the list of available references, and put a
check mark next to it.

 

[Douglas J. Steele]

You need to set a reference to Outlook for that code to work.

While in the VB Editor, select Tools | References from the menu bar. Scroll
through the list of available references until you find the one for
Microsoft Outlook x.0 Object Library (where x will depend on what version of
Outlook you have installed.) Check it, then close the dialog.

Alternatively, change:

Dim objOutlook As Outlook.Application
Dim objEmail As Outlook.MailItem

Set objOutlook = CreateObject("Outlook.application")
Set objEmail = objOutlook.CreateItem(olMailItem)

to

Dim objOutlook As Object
Dim objEmail As Object

Set objOutlook = CreateObject("Outlook.application")
Set objEmail = objOutlook.CreateItem(0)

 

[Ecapodieci via AccessMonster.com]

I knew it was soemthing that i wasnt doing. Thanks a million.

How would one know what references to enable when doing something like this.
In this case it was easy because im specifically doing something with Outlook,
but in other cases what is best practice? Do these references need to be
enabled in ever database that has modules or is it something the VBA
rememebrs and uses for all modules regardless of which database they are in?

emanuele

Why is it whenever i an trying to declare variables such as...

[quoted text clipped - 5 lines]

attempt to use them, i get this error. It' spretty frustrating, but
it's probably something i should know.

To use early binding (declaring as a specific object type, rather than
just as Object), you have to set a reference to the object library or
type library that defines the object. In this case, you'd need to click
Tools -> References... in the VB Editor, locate the Microsoft Outlook
<version> Object Library in the list of available references, and put a
check mark next to it.

 

[Dirk Goldgar]

I knew it was soemthing that i wasnt doing. Thanks a million.

How would one know what references to enable when doing something
like this. In this case it was easy because im specifically doing
something with Outlook, but in other cases what is best practice?

You pretty much have to know what object model you want to work with,
then look in the list of available references to find the appropriate
library. There are some that are more obscure, such as scripting,
regular expressions, and so forth, but you can usually find out what you
need by reading documentation or searching the newsgroups or the web.

Do
these references need to be enabled in ever database that has modules
or is it something the VBA rememebrs and uses for all modules
regardless of which database they are in?

The references you select are specific to the database file, and travel
with it if you copy it from one PC to another. HOWEVER, the libraries
you reference may not be present on all PCs, and even if they are, the
specific version you have referenced may not be present on the machine
you've copied to. This can cause errors due to what are called
"missing" or "broken" references. The most common result of broken
references is that simple calls to VBA functions stop working. Such
errors are relatively easy to fix if a version of the library you want
exists on the target PC -- see

http://www.accessmvp.com/djsteele/AccessReferenceErrors.html

-- but of course you're out of luck if the application or run-time
library you want to manipulate isn't present at all.

Because of the problems caused by different reference versions on
different PCs, developers often use "late binding" when preparing Access
applications for distribution. They drop the reference altogether, use
non-type-specific object declarations (e.g., "Dim objOutlook As
Object"), and use literals in place of the constants that are defined in
the object library. See Doug Steele's post in this thread.

You don't normally have to worry about this when working with those
references that Access itself defines:

Microsoft Access <version> Object Library
Visual Basic for Applications
OLE Automation

You'll often also have a reference to one or both of

Microsoft DAO 3.6 Object Library
Microsoft ActiveX Data Objects 2.<x> Library

The DAO reference doesn't usually break, but different computers may
have different versions of the ADO (ActiveX Data Objects) library. For
most purposes, DAO is better for working with data stored in Access
(Jet) databases, anyway, so I usually un-check the ADO reference.

 

[Ecapodieci via AccessMonster.com]

Well, this makes me a little bit happier knowing that it wasnt something so
easy that i was missing. I think i will read up on these references in case i
need to know them or i work with some code that contains these references. It
seems more intuitive to use the DIM objOutlook AS Object. From what i gather
it is more user friendly and causes fewer errors down the road.

Thanks for you help Dirk and Doug.

 

[Douglas J. Steele]

I don't see how it's "more user friendly", but it can definitely cause fewer
errors down the road. If you built the application using a specific version
of the referenced application, and your users have a different version of
that application installed, you can run into problems that will cause the
entire database to stop working (not just the parts that involve the
referenced application). Using Late Binding can minimize that sort of
problems.

However, with Late Binding you have to remember to define the constants that
belong to the application you're referencing. Remember that your original
code had

Set objEmail = objOutlook.CreateItem(olMailItem)

in it. olMailItem is a constant defined by the Outlook library. You either
need to include

Const olMailItem = 0

in your code, or else replace the named constant with its value in your
function calls:

Set objEmail = objOutlook.CreateItem(0)

To me, using named constants is definitely superior.

To get the best of both worlds, you can add the reference while you're
coding. In that way, you'll get intellisense working, which should help you
with your code. Once you've got the code working, make sure all of the
constants are defined, then remove the reference before you distribute to
your users.