By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,830 Members | 682 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,830 IT Pros & Developers. It's quick & easy.

Late binding now failing

P: n/a
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
Nov 12 '05 #1
Share this Question
Share on Google+
21 Replies


P: n/a
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.

HTH
- Turtle

"Mike MacSween" <mi******************@btinternet.com> wrote in message
news:3f*********************@pubnews.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(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

Nov 12 '05 #2

P: n/a
Mike,

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

?wdSendToNewDocument

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...
Nov 12 '05 #3

P: n/a
"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
Nov 12 '05 #4

P: n/a
"Pieter Linden" <pi********@hotmail.com> wrote in message
news:bf**************************@posting.google.c om...
Mike,

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

?wdSendToNewDocument


Thanks Pieter, that did it.

Cheers, Mike
Nov 12 '05 #5

P: n/a
"Mike MacSween" <mi******************@btinternet.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
Nov 12 '05 #6

P: n/a
"Mike MacSween" <mi******************@btinternet.com> wrote in
news:3f*********************@pubnews.gradwell.net:
"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. 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)
Nov 12 '05 #7

P: n/a
"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
Nov 12 '05 #8

P: n/a
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.

HTH
- Turtle

"Mike MacSween" <mi******************@btinternet.com> wrote in message
news:3f*********************@pubnews.gradwell.net. ..
"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

Nov 12 '05 #9

P: n/a
"MacDermott" <ma********@nospam.com> wrote in message
news:2K******************@newsread2.news.atl.earth link.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 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.


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
Nov 12 '05 #10

P: n/a
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.
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.

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

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

Those are all rational reasons for shipping MDEs.

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

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #11

P: n/a
mi******************@btinternet.com (Mike MacSween) wrote in
<3f*********************@pubnews.gradwell.net>:
"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.


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.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #12

P: n/a
ma********@nospam.com (MacDermott) wrote in
<2K******************@newsread2.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 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.


When VBA code is compiled, constants are compiled in literally, not
as references to the variable name. If you refer to a constant
value for an object that hasn't been instantiated, it can't
possibly be compiled in literally.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #13

P: n/a
mi******************@btinternet.com (Mike MacSween) wrote in
<3f*********************@pubnews.gradwell.net>:
"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.


What I've done is copied the constant declarations as comments at
the top of the code using them:
' wdDefaultFirstRecord = 1

and then use the literal value in the actual code, but with the
named constant as a trailing comment:

.FirstRecord = 1 ' wdDefaultFirstRecord

This means I only have to change the definitions of the objects
themselves, but still have an audit trail back into the constant
names (particularly useful if you're trying to reconcile your
late-bound code with other code that's early bound).

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #14

P: n/a
"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.

Cheers, Mike
Nov 12 '05 #15

P: n/a
"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?

Yours, Mike MacSween
Nov 12 '05 #16

P: n/a
mi******************@btinternet.com (Mike MacSween) wrote in
<3f***********************@pubnews.gradwell.net> :
"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,


The idea came to me from MichKa, I'm pretty sure.
>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.


That takes care of the accidental scenario, but somebody could
still change the code on purpose with an MDB.
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?


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 http://www.bway.net/~dfenton
8dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #17

P: n/a
mi******************@btinternet.com (Mike MacSween) wrote in
<3f***********************@pubnews.gradwell.net> :
"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.


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.

On the other hand, putting in literal values isn't necessarily
better.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #18

P: n/a
"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.

Yours, Mike MacSween
Nov 12 '05 #19

P: n/a
"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.

Cheers, Mike MacSween
Nov 12 '05 #20

P: n/a
mi******************@btinternet.com (Mike MacSween) wrote in
<3f***********************@pubnews.gradwell.net> :
"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?


Even your ubiquitous error-handlers won't fix that if the result is
uncompilable.
>> 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.


I doubt you'll notice any differnces, but it would be interesting
for you to compare the size of the MDEs vs. MDBs after, say, a
month of usage.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #21

P: n/a
mi******************@btinternet.com (Mike MacSween) wrote in
<3f***********************@pubnews.gradwell.net> :
"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.


I understand.

My point is that I wouldn't bother with actual declarations. I
would include them in the comments, though, as well as commenting
the literal values, as I said in my earlier post. That way I
wouldn't have to alter the code for distribution, except for
changing the objects themselves.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #22

This discussion thread is closed

Replies have been disabled for this discussion.