Late binding now failing

[Mike MacSween]

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(strQu ery As String, strTemplate As String)
snip
Dim doc As Word.Document
Dim wrdApp As Word.Applicatio n
snip

Set wrdApp = New Word.Applicatio n
Set doc = wrdApp.Document s.Add(strPath & strTemplate)

With doc.MailMerge
..Destination = wdSendToNewDocu ment
..SuppressBlank Lines = True
With .DataSource
..FirstRecord = wdDefaultFirstR ecord
..LastRecord = wdDefaultLastRe cord
End With
If .State = wdMainAndDataSo urce 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(strQu ery As String, strTemplate As String)
snip
Dim doc As object
Dim wrdApp as object
snip

Set wrdApp = CreateObject("W ord.Application ")
Set doc = wrdApp.Document s.Add(strPath & strTemplate)

With doc.MailMerge
..Destination = wdSendToNewDocu ment
..SuppressBlank Lines = True
With .DataSource
..FirstRecord = wdDefaultFirstR ecord
..LastRecord = wdDefaultLastRe cord
End With
If .State = wdMainAndDataSo urce Then .Execute
End With
wrdApp.Visible = True
snip
End Sub
*************** *************** *************** ************
it halts on
..Destination = wdSendToNewDocu ment
with wdSendToNewDocu ment highlighted and 'unknown variable'

Any ideas?

TIA, Mike MacSween

[MacDermott]

wdSendToNewDocu ment
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
wdSendToNewDocu ment
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.

HTH
- Turtle

"Mike MacSween" <mi************ ******@btintern et.com> wrote in message
news:3f******** *************@p ubnews.gradwell .net...

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(strQu ery As String, strTemplate As String)
snip
Dim doc As Word.Document
Dim wrdApp As Word.Applicatio n
snip

Set wrdApp = New Word.Applicatio n
Set doc = wrdApp.Document s.Add(strPath & strTemplate)

With doc.MailMerge
.Destination = wdSendToNewDocu ment
.SuppressBlankL ines = True
With .DataSource
.FirstRecord = wdDefaultFirstR ecord
.LastRecord = wdDefaultLastRe cord
End With
If .State = wdMainAndDataSo urce 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(strQu ery As String, strTemplate As String)
snip
Dim doc As object
Dim wrdApp as object
snip

Set wrdApp = CreateObject("W ord.Application ")
Set doc = wrdApp.Document s.Add(strPath & strTemplate)

With doc.MailMerge
.Destination = wdSendToNewDocu ment
.SuppressBlankL ines = True
With .DataSource
.FirstRecord = wdDefaultFirstR ecord
.LastRecord = wdDefaultLastRe cord
End With
If .State = wdMainAndDataSo urce Then .Execute
End With
wrdApp.Visible = True
snip
End Sub
*************** *************** *************** ************
it halts on
.Destination = wdSendToNewDocu ment
with wdSendToNewDocu ment highlighted and 'unknown variable'

Any ideas?

TIA, Mike MacSween

[Pieter Linden]

Mike,

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

?wdSendToNewDoc ument

in the immediate window, get the number/value associated with this
variable and use that number instead? Does it work?

just a haphazard guess, so don't spend any more than 30 seconds
playing with it...

[Mike MacSween]

"MacDermott " <ma********@nos pam.com> wrote in message
news:WF******** **********@news read1.news.atl. earthlink.net.. .

wdSendToNewDocu ment
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 wdSendToNewDocu ment
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

[Mike MacSween]

"Pieter Linden" <pi********@hot mail.com> wrote in message
news:bf******** *************** ***@posting.goo gle.com...

Mike,

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

?wdSendToNewDoc ument

Thanks Pieter, that did it.

Cheers, Mike

[Tony Toews]

"Mike MacSween" <mi************ ******@btintern et.com> wrote:

No idea as to why constants can't be used. That said someone stated that he didn't
have any problem leaving the constants in the Access app when he changed back to
early binding for some more programming.

So you could Const them at the top of a module anyhow.

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.

To me the issue is "Could there be a different version of xxx to which you have a
reference?" If Outlook, Word, Excel, ... then that's a very good possibility even
if in one organization. For example, and this happened to me, the IT guy upgraded
his version of Outlook just to play with things. And it promptly broke the app which
automatically sent out emails via Outlook for him.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

[Lyle Fairfield]

"Mike MacSween" <mi************ ******@btintern et.com> wrote in
news:3f******** *************@p ubnews.gradwell .net:

"MacDermott " <ma********@nos pam.com> wrote in message
news:WF******** **********@news read1.news.atl. earthlink.net.. .

wdSendToNewDocu ment
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

wdSendToNewDocu ment
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. 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.

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
(for e-mail refer to http://ffdba.com/contacts.htm)

[Mike MacSween]

"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.
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.

Don't know about 3 and 4, they're in the American Colonies, yes? I know what
you mean about 1 and 2 though.

Mike

[MacDermott]

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 wdSendToNewDocu ment 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.

HTH
- Turtle

"Mike MacSween" <mi************ ******@btintern et.com> wrote in message
news:3f******** *************@p ubnews.gradwell .net...

"MacDermott " <ma********@nos pam.com> wrote in message
news:WF******** **********@news read1.news.atl. earthlink.net.. .

wdSendToNewDocu ment
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

wdSendToNewDocu ment
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

[Mike MacSween]

"MacDermott " <ma********@nos pam.com> wrote in message
news:2K******** **********@news read2.news.atl. earthlink.net.. .

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 wdSendToNewDocu ment 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.

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.

Thanks for your help.

Mike