I'm trying to port working Word VBA code into an Excel VBA module.
Because I don't know which version of Word my users have, I'm writing
it as late-binding code (everything Word is Dim'd as Object). I think
'most everything is going okay so far (we'll find out when I smoke
test!), but I'm wondering about certain Word objects that use methods
and properties not found in Excel.

My question is: when the Word Application object is set and the other
Word objects (docs and ranges) are set, will they be able to access
all the properties and methods of the Word object as if they were
early-bound?

For instance:
rngDoc.Find.Execute _
FindText:="MyText"
Excel Find does not have the Execute method nor the FindText property.

and

rngDoc.MoveEnd Unit:=wdParagraph
likewise has no Excel equivalent.

Should this compile and run okay? Or am I going to have to find new
ways to write this that are compatible with a late-binding routine?

Ed

The properties and methods should be just fine. Once bound to the object at
run time all of the properties and methods of the object will be exposed.
Where you can have an issue is with constants like wdBorderLeft which will
not exist. You will need to replace those constants with their numeric
equivalent (-2 in this case) or you can declare the constants publicly in a
module

Public Const wdBorderLeft as Long = -2

(I kinda like that option as it makes things a bit more readable but to each
his own)
--
HTH...

Jim Thomlinson


"Ed from AZ" wrote:

I'm trying to port working Word VBA code into an Excel VBA module.
Because I don't know which version of Word my users have, I'm writing
it as late-binding code (everything Word is Dim'd as Object). I think
'most everything is going okay so far (we'll find out when I smoke
test!), but I'm wondering about certain Word objects that use methods
and properties not found in Excel.

My question is: when the Word Application object is set and the other
Word objects (docs and ranges) are set, will they be able to access
all the properties and methods of the Word object as if they were
early-bound?

For instance:
rngDoc.Find.Execute _
FindText:="MyText"
Excel Find does not have the Execute method nor the FindText property.

and

rngDoc.MoveEnd Unit:=wdParagraph
likewise has no Excel equivalent.

Should this compile and run okay? Or am I going to have to find new
ways to write this that are compatible with a late-binding routine?

Ed

Thanks, Jim. I appreciate the boost.

The next question, then, is how to find the constants? Is there an on-
line reference, perhaps? Or do I just have to hunt-and-peck each one
in Word VBA?

Ed

On Aug 28, 2:32 pm, Jim Thomlinson <James_Thomlin...@owfg-Re-Move-
This-.com wrote:
The properties and methods should be just fine. Once bound to the object at
run time all of the properties and methods of the object will be exposed.
Where you can have an issue is with constants like wdBorderLeft which will
not exist. You will need to replace those constants with their numeric
equivalent (-2 in this case) or you can declare the constants publicly in a
module

Public Const wdBorderLeft as Long = -2

(I kinda like that option as it makes things a bit more readable but to each
his own)
--
HTH...

Jim Thomlinson



"Ed from AZ" wrote:
I'm trying to port working Word VBA code into an Excel VBA module.
Because I don't know which version of Word my users have, I'm writing
it as late-binding code (everything Word is Dim'd as Object). I think
'most everything is going okay so far (we'll find out when I smoke
test!), but I'm wondering about certain Word objects that use methods
and properties not found in Excel.

My question is: when the Word Application object is set and the other
Word objects (docs and ranges) are set, will they be able to access
all the properties and methods of the Word object as if they were
early-bound?

For instance:
rngDoc.Find.Execute _
FindText:="MyText"
Excel Find does not have the Execute method nor the FindText property.

and

rngDoc.MoveEnd Unit:=wdParagraph
likewise has no Excel equivalent.

Should this compile and run okay? Or am I going to have to find new
ways to write this that are compatible with a late-binding routine?

Ed- Hide quoted text -

- Show quoted text -

Make sure that you have Option Explicit declared at the top of each code
module so that VBA won't declare those as varaibles for you on the fly. Now
your code will not compile if any of those constants exist. Once you have
found them go into Word VBA and hit F2 to bring up a listing of all of the
objects and constants and such. When you find the constants you are looking
for select them and you will be given the value associated with that constant.
--
HTH...

Jim Thomlinson


"Ed from AZ" wrote:

Thanks, Jim. I appreciate the boost.

The next question, then, is how to find the constants? Is there an on-
line reference, perhaps? Or do I just have to hunt-and-peck each one
in Word VBA?

Ed

On Aug 28, 2:32 pm, Jim Thomlinson <James_Thomlin...@owfg-Re-Move-
This-.com wrote:
The properties and methods should be just fine. Once bound to the object at
run time all of the properties and methods of the object will be exposed.
Where you can have an issue is with constants like wdBorderLeft which will
not exist. You will need to replace those constants with their numeric
equivalent (-2 in this case) or you can declare the constants publicly in a
module

Public Const wdBorderLeft as Long = -2

(I kinda like that option as it makes things a bit more readable but to each
his own)
--
HTH...

Jim Thomlinson



"Ed from AZ" wrote:
I'm trying to port working Word VBA code into an Excel VBA module.
Because I don't know which version of Word my users have, I'm writing
it as late-binding code (everything Word is Dim'd as Object). I think
'most everything is going okay so far (we'll find out when I smoke
test!), but I'm wondering about certain Word objects that use methods
and properties not found in Excel.

My question is: when the Word Application object is set and the other
Word objects (docs and ranges) are set, will they be able to access
all the properties and methods of the Word object as if they were
early-bound?

For instance:
rngDoc.Find.Execute _
FindText:="MyText"
Excel Find does not have the Execute method nor the FindText property.

and

rngDoc.MoveEnd Unit:=wdParagraph
likewise has no Excel equivalent.

Should this compile and run okay? Or am I going to have to find new
ways to write this that are compatible with a late-binding routine?

Ed- Hide quoted text -

- Show quoted text -

Jim, this all worked great!! Thank you so much!

Ed


On Aug 28, 3:06 pm, Jim Thomlinson <James_Thomlin...@owfg-Re-Move-
This-.com wrote:
Make sure that you have Option Explicit declared at the top of each code
module so that VBA won't declare those as varaibles for you on the fly. Now
your code will not compile if any of those constants exist. Once you have
found them go into Word VBA and hit F2 to bring up a listing of all of the
objects and constants and such. When you find the constants you are looking
for select them and you will be given the value associated with that constant.
--
HTH...

Jim Thomlinson



"Ed from AZ" wrote:
Thanks, Jim. I appreciate the boost.

The next question, then, is how to find the constants? Is there an on-
line reference, perhaps? Or do I just have to hunt-and-peck each one
in Word VBA?

Ed

On Aug 28, 2:32 pm, Jim Thomlinson <James_Thomlin...@owfg-Re-Move-
This-.com wrote:
The properties and methods should be just fine. Once bound to the object at
run time all of the properties and methods of the object will be exposed.
Where you can have an issue is with constants like wdBorderLeft which will
not exist. You will need to replace those constants with their numeric
equivalent (-2 in this case) or you can declare the constants publicly in a
module

Public Const wdBorderLeft as Long = -2

(I kinda like that option as it makes things a bit more readable but to each
his own)
--
HTH...

Jim Thomlinson

"Ed from AZ" wrote:
I'm trying to port working Word VBA code into an Excel VBA module.
Because I don't know which version of Word my users have, I'm writing
it as late-binding code (everything Word is Dim'd as Object). I think
'most everything is going okay so far (we'll find out when I smoke
test!), but I'm wondering about certain Word objects that use methods
and properties not found in Excel.

My question is: when the Word Application object is set and the other
Word objects (docs and ranges) are set, will they be able to access
all the properties and methods of the Word object as if they were
early-bound?

For instance:
rngDoc.Find.Execute _
FindText:="MyText"
Excel Find does not have the Execute method nor the FindText property.

and

rngDoc.MoveEnd Unit:=wdParagraph
likewise has no Excel equivalent.

Should this compile and run okay? Or am I going to have to find new
ways to write this that are compatible with a late-binding routine?

Ed- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -