Late binding now failing

Had some trouble with Word automation. Sorted it, in the process thought I
would try late binding. Some people reccomend it. So this:
************************************************** *******
Public Sub MailMerge(strQuery As String, strTemplate As String)
snip
Dim doc As Word.Document
Dim wrdApp As Word.Application
snip

Set wrdApp = New Word.Application
Set doc = wrdApp.Documents.Add(strPath & strTemplate)

With doc.MailMerge
.Destination = wdSendToNewDocument
.SuppressBlankLines = True
With .DataSource
.FirstRecord = wdDefaultFirstRecord
.LastRecord = wdDefaultLastRecord
End With
If .State = wdMainAndDataSource Then .Execute
End With
wrdApp.Visible = True
snip
End Sub
************************************************** *******
works, with a reference to the Word olb

If i change it to:
************************************************** *******
Public Sub MailMerge(strQuery As String, strTemplate As String)
snip
Dim doc As object
Dim wrdApp as object
snip

Set wrdApp = CreateObject("Word.Application")
Set doc = wrdApp.Documents.Add(strPath & strTemplate)

With doc.MailMerge
.Destination = wdSendToNewDocument
.SuppressBlankLines = True
With .DataSource
.FirstRecord = wdDefaultFirstRecord
.LastRecord = wdDefaultLastRecord
End With
If .State = wdMainAndDataSource Then .Execute
End With
wrdApp.Visible = True
snip
End Sub
************************************************** *******
it halts on
.Destination = wdSendToNewDocument
with wdSendToNewDocument highlighted and 'unknown variable'

Any ideas?

TIA, Mike MacSween

wdSendToNewDocument
is defined in the Word olb.
If you don't have a reference to that library, you can't resolve this name.
If you do have a reference to the library, you can find the numeric value of wdSendToNewDocument
and put that into your code. I see there are a couple more of these terms
from the Word olb you'll have to do the same with if you want to remove the reference to the olb.

Mike,

wdSendToNewDocument is a named constant or something like that. What
if you cheat and do something like

?wdSendToNewDocument

Not sure which way to swing on this now. There seems to be a conflict. All
the literature says 'use early binding unless there's a very good reason not
to' whereas a lot of people say use late binding. Some advise using early in
development (to get the intellisense etc.) then change to late for
distribution. But if I'm going to have to find constant values myself that
loses some advantage. And I read to always use late if using MDEs.

"MacDermott" <ma********@nospam.com> wrote in message
news:WF******************@newsread1.news.atl.earth link.net...

wdSendToNewDocument
is defined in the Word olb.
If you don't have a reference to that library, you can't resolve this

name.

If you do have a reference to the library, you can find the numeric
value

of

wdSendToNewDocument
and put that into your code. I see there are a couple more of these
terms from the Word olb you'll have to do the same with if you want to
remove

the

reference to the olb.

Thanks Turtle, that worked perfectly. Though I don' really understand.
If using CreateObject() to use automation gives me access to the Word
methods and properties, why not the constants?

Not sure which way to swing on this now. There seems to be a conflict.
All the literature says 'use early binding unless there's a very good
reason not to' whereas a lot of people say use late binding. Some advise
using early in development (to get the intellisense etc.) then change to
late for distribution. But if I'm going to have to find constant values
myself that loses some advantage. And I read to always use late if using
MDEs.

Whaddya think?

Cheers, Mike

The constants are contained in the type library, not in the object. And
late binding does not require a type library, it simply binds the object's
name to its Dispatch ID.
Got it (I think):

object.property = 1

but if you want you can refer to 1 by saying "wdNewDoc", but only if you use
our library, where we've enumerated the constants. Or something like that.
It does this at run-time, so if there's a problem,
that's when it will arise. Many developers want to know about problems at
compile time and so, even if the claimed speed advantage of early binding
seems to be exaggerated, they prefer early.
Yes, I can see that. Many developers would include me. But of course I'd
also like to know that something that runs just fine here, won't fall to
bits when it goes onto a client's machine, just because they have build
version 9.34.34.4334 of MS OfficeProduct, which is one build later than
mine. Does location make a difference? For instance I always install Office
into C:\Office XXX, with having so many different versions, whereas clients
will usually/often have the default of c:\program files\etc.

I can see the advantages of develop early, deploy late. (Does that sound
like some sort of new 'developement paradigm')
A problem with MDEs is that references cannot be changed. Perhaps, that is
why late binding is recommended for MDEs.
I just like the idea of stopping people tinkering! That's my job.
IMO MDEs are sound devices for
those who write entirely original and supremely valuable code.
See, you've been looking at my code again. If compiled to an MDE!
They are
also helpful for the paranoid and those whose experience is so limited that they think that they have created something wonderful and unique. I am
paranoid only about the Fascist Right, Religious Fundamentalists, the New
York Yankees, the USA Olympic Committee and other such nefarious groups.

"MacDermott" <ma********@nospam.com> wrote in message
news:WF******************@newsread1.news.atl.earth link.net...

wdSendToNewDocument
is defined in the Word olb.
If you don't have a reference to that library, you can't resolve this name.

If you do have a reference to the library, you can find the numeric value of

wdSendToNewDocument
and put that into your code. I see there are a couple more of these

terms from the Word olb you'll have to do the same with if you want to remove

the

reference to the olb.

Thanks Turtle, that worked perfectly. Though I don' really understand. If
using CreateObject() to use automation gives me access to the Word methods
and properties, why not the constants?

Not sure which way to swing on this now. There seems to be a conflict. All
the literature says 'use early binding unless there's a very good reason

not to' whereas a lot of people say use late binding. Some advise using early in development (to get the intellisense etc.) then change to late for
distribution. But if I'm going to have to find constant values myself that
loses some advantage. And I read to always use late if using MDEs.

Whaddya think?

Cheers, Mike

Here's another way of thinking of it:
Access doesn't know that you're making wrd into a Word object until
CreateObject is executed -
long after compile time, when it's trying to resolve constants, and notices it doesn't know what wdSendToNewDocument means.
(Actually, as one poster comments, it doesn't even recognize the
constant after the object has been created, because the definition is in the type library, not the object library.)
Yes, I understand
Personally, in such cases I like the solution of declaring constants at the top of your module.

The constants are contained in the type library, not in the
object. And late binding does not require a type library, it
simply binds the object's name to its Dispatch ID. It does this at
run-time, so if there's a problem, that's when it will arise. Many
developers want to know about problems at compile time and so,
even if the claimed speed advantage of early binding seems to be
exaggerated, they prefer early.
I code with early binding, deliver with late.
A problem with MDEs is that references cannot be changed. Perhaps,
that is why late binding is recommended for MDEs. IMO MDEs are
sound devices for those who write entirely original and supremely
valuable code. They are also helpful for the paranoid and those
whose experience is so limited that they think that they have
created something wonderful and unique. I am paranoid only about
the Fascist Right, Religious Fundamentalists, the New York
Yankees, the USA Olympic Committee and other such nefarious
groups. So I don't use MDEs. And I know that I am neither
wonderful nor unique. Consider my evil twin, Kyle ...

"Lyle Fairfield" <Mi************@Invalid.Com> wrote in message
news:Xn*******************@130.133.1.4...

The constants are contained in the type library, not in the
object. And late binding does not require a type library, it
simply binds the object's name to its Dispatch ID.

Got it (I think):

object.property = 1

but if you want you can refer to 1 by saying "wdNewDoc", but only
if you use our library, where we've enumerated the constants. Or
something like that.

Here's another way of thinking of it:
Access doesn't know that you're making wrd into a Word object
until
CreateObject is executed -
long after compile time, when it's trying to resolve
constants, and
notices it doesn't know what wdSendToNewDocument means.
(Actually, as one poster comments, it doesn't even
recognize the
constant after the object has been created, because the definition
is in the type library, not the object library.)

Personally, in such cases I like the solution of declaring
constants at the top of your module.

"MacDermott" <ma********@nospam.com> wrote in message
news:2K******************@newsread2.news.atl.eart hlink.net...

Personally, in such cases I like the solution of declaring
constants at

the

top of your module.

I just worked that out. I guess a strategy would be to start with
early binding (nice intellisense), compile (nice type checking),
then remove the reference. Then compile and each time it chokes
change first the early binding declaration and then each constant
as it chokes on them one by one.

In Access terms it would be like this:

In mdlWord:

Private Const wdNewDoc = 1

If you run code from mdlNotWord, it won't know the value of
wdNewDoc because the constant is not public.

The object reference is your link to the otherwise "private"
constants of Word.

Keep in mind that even though you create the object, you are still
*acting* on that object in Access, not in Word itself, so the
constants need to be known to Access itself.

Mi************@Invalid.Com (Lyle Fairfield) wrote in
<Xn*******************@130.133.1.4>:

The constants are contained in the type library, not in the
object. And late binding does not require a type library, it
simply binds the object's name to its Dispatch ID. It does this at
run-time, so if there's a problem, that's when it will arise. Many
developers want to know about problems at compile time and so,
even if the claimed speed advantage of early binding seems to be
exaggerated, they prefer early.
I code with early binding, deliver with late.

Yes, it was you gave me the idea, I think,

A problem with MDEs is that references cannot be changed. Perhaps,
that is why late binding is recommended for MDEs. IMO MDEs are
sound devices for those who write entirely original and supremely
valuable code. They are also helpful for the paranoid and those
whose experience is so limited that they think that they have
created something wonderful and unique. I am paranoid only about
the Fascist Right, Religious Fundamentalists, the New York
Yankees, the USA Olympic Committee and other such nefarious
groups. So I don't use MDEs. And I know that I am neither
wonderful nor unique. Consider my evil twin, Kyle ...

MDE's have a number of advantages not related to your arrogance
argument:

1. the code cannot be changed. This means that you don't have to
consider whether or not a user has gotten in there and made a
change, accidentally or not. I've seen it accidentally when an
untrapped error gets the user into debug mode, and they hit the
ENTER key or otherwise type some character. This will quite often
lead to permanently broken, uncompilable code (assuming the changes
are saved). With an MDE, this simply can't ever happen, so it
streamlines troubleshooting.

Sounds like a pretty damn good idea. Though I have custom error handling in
EVERY single procedure. I know we disagree about whether that's really
necessary, but:

a) It's very quick for me to do, using a 3rd party tool
b) It means (or I think it will mean, to be more accurate) that users will
never see the debug button on an error message.
2. the code can never decompile, so performance can never degrade
because of decompiled code.
Another good reason
3. performance can be noticeably better, both because of smaller
file size but also because 2) can't happen.
And again
Those are all rational reasons for shipping MDEs.
Yes
That said, I've got no current projects delivered as MDEs.

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:94***************************@24.168.128.74. ..

Mi************@Invalid.Com (Lyle Fairfield) wrote in
<Xn*******************@130.133.1.4>:

>The constants are contained in the type library, not in the
>object. And late binding does not require a type library, it
>simply binds the object's name to its Dispatch ID. It does this
>at run-time, so if there's a problem, that's when it will
>arise. Many developers want to know about problems at compile
>time and so, even if the claimed speed advantage of early
>binding seems to be exaggerated, they prefer early.

I code with early binding, deliver with late.

Yes, it was you gave me the idea, I think,

>A problem with MDEs is that references cannot be changed.
>Perhaps, that is why late binding is recommended for MDEs. IMO
>MDEs are sound devices for those who write entirely original
>and supremely valuable code. They are also helpful for the
>paranoid and those whose experience is so limited that they
>think that they have created something wonderful and unique. I
>am paranoid only about the Fascist Right, Religious
>Fundamentalists, the New York Yankees, the USA Olympic
>Committee and other such nefarious groups. So I don't use MDEs.
>And I know that I am neither wonderful nor unique. Consider my
>evil twin, Kyle ...

MDE's have a number of advantages not related to your arrogance
argument:

1. the code cannot be changed. This means that you don't have to
consider whether or not a user has gotten in there and made a
change, accidentally or not. I've seen it accidentally when an
untrapped error gets the user into debug mode, and they hit the
ENTER key or otherwise type some character. This will quite
often lead to permanently broken, uncompilable code (assuming
the changes are saved). With an MDE, this simply can't ever
happen, so it streamlines troubleshooting.

Sounds like a pretty damn good idea. Though I have custom error
handling in EVERY single procedure. I know we disagree about
whether that's really necessary, but:

a) It's very quick for me to do, using a 3rd party tool
b) It means (or I think it will mean, to be more accurate) that
users will never see the debug button on an error message.

2. the code can never decompile, so performance can never
degrade because of decompiled code.

Another good reason

3. performance can be noticeably better, both because of smaller
file size but also because 2) can't happen.

And again

Those are all rational reasons for shipping MDEs.

Yes

That said, I've got no current projects delivered as MDEs.

Oh. Why not then?

"David W. Fenton" <dX********@bway.net.invalid> wrote in message

In Access terms it would be like this:

In mdlWord:

Private Const wdNewDoc = 1

If you run code from mdlNotWord, it won't know the value of
wdNewDoc because the constant is not public.

The object reference is your link to the otherwise "private"
constants of Word.

Keep in mind that even though you create the object, you are
still *acting* on that object in Access, not in Word itself, so
the constants need to be known to Access itself.

Thanks David. I'm declaring thus:

Public Sub MailMerge(strQuery As String, strTemplate As String)
Const wdSendToNewDocument As Integer = 0
more declarations here
some code here
End sub

So they're still local variables, even though the procedure's
public, yes? Which is what I want. Though it's highly unlikely
that I'm going to be declaring any other variable with the same
names as these (except to do exactly the same thing) anyway.
Still, I can't see any need for them to be public.

Public Sub MailMerge(strQuery As String, strTemplate As String)
Const wdSendToNewDocument As Integer = 0
more declarations here
some code here
End sub

So they're still local variables, even though the procedure's
public, yes? Which is what I want. Though it's highly unlikely
that I'm going to be declaring any other variable with the same
names as these (except to do exactly the same thing) anyway.
Still, I can't see any need for them to be public.

I wouldn't declare the variables there because then when you are
working with early binding, you'll have two declarations, the local
one and the one in the Word OLB. I know it doesn't actually
conflict, but it bothers me.

Sounds like a pretty damn good idea. Though I have custom error
handling in EVERY single procedure. I know we disagree about
whether that's really necessary, but:

a) It's very quick for me to do, using a 3rd party tool
b) It means (or I think it will mean, to be more accurate) that
users will never see the debug button on an error message.

That takes care of the accidental scenario, but somebody could
still change the code on purpose with an MDB.

That said, I've got no current projects delivered as MDEs.

Oh. Why not then?

Too much trouble, as I don't have any projects that are ever
*finished*. MDBs make debugging beta versions a lot easier, since
the code is there to be displayed in debug mode.

Yes, I'm lazy, but it would cost my clients a lot more to do
otherwise. And I have good clients who work with me on these kinds
of things extremely well.

"David W. Fenton" <dX********@bway.net.invalid> wrote in message

>Sounds like a pretty damn good idea. Though I have custom error
>handling in EVERY single procedure. I know we disagree about
>whether that's really necessary, but:
>
>a) It's very quick for me to do, using a 3rd party tool
>b) It means (or I think it will mean, to be more accurate) that
>users will never see the debug button on an error message.

That takes care of the accidental scenario, but somebody could
still change the code on purpose with an MDB.

True. But we were talking really about the accidental one. You
know, somebody gets an unhandled error, ends up at the debug
window and types something and then?

>> That said, I've got no current projects delivered as MDEs.
>
>Oh. Why not then?

Too much trouble, as I don't have any projects that are ever
*finished*. MDBs make debugging beta versions a lot easier,
since the code is there to be displayed in debug mode.

Yes, I'm lazy, but it would cost my clients a lot more to do
otherwise. And I have good clients who work with me on these
kinds of things extremely well.

I'll see. I'm about to install about 10 copies of the same FE. I
may try half as MDEs, just as a test to detect any differences.

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
tself.

>Public Sub MailMerge(strQuery As String, strTemplate As String)
>Const wdSendToNewDocument As Integer = 0
>more declarations here
>some code here
>End sub
>
>So they're still local variables, even though the procedure's
>public, yes? Which is what I want. Though it's highly unlikely
>that I'm going to be declaring any other variable with the same
>names as these (except to do exactly the same thing) anyway.
>Still, I can't see any need for them to be public.

I wouldn't declare the variables there because then when you are
working with early binding, you'll have two declarations, the
local one and the one in the Word OLB. I know it doesn't
actually conflict, but it bothers me.

I mean when I using late binding, that's how I'll declare them.
But comment the declaration out while I'm using early binding in
development.