VanS,

With late binding you would declare all of the data types that are declared
within the library in question as Object. That is the simple bit. You also
have to create the object, as against using the VB Set statement to create
an object of that. With the extensibility library, you don't usually need to
create anything, you can just do code like

Dim VBComp As Object

Set VBComp = ThisWorkbook.VBProject.vbcomponents("Module2")
ThisWorkbook.VBProject.vbcomponents.Remove VBComp

But this does nothing to resolve the issue Tom and I have discussed with
you. If you develop in a later version of Excel, you are likely to use
functionality that won't work with the earlier version. Late binding does
not solve this in any form.

--

HTH

RP
(remove nothere from the email address if mailing direct)


"VanS" wrote in message
...
Bob,
Thanks again for your reply.
From the research I have done, late binding seems to be the preferable and
recommended way of dealing with Office compatibility across multiple
versions. In looking at MS KB articles (244224 & 269116) on the issue with
reference to the VBA Extensibility library, the answers they recommended
were
late binding also.
They gave an example of changing:
Dim ojbVBProjs as VBIDE.VBProjects to
Dim objVBProjs as Object
I am still learning about these aspects of VBA but I don't have any
declarations as the first one above. My app just has selected the
reference
for the VBA Extensibility 5.3 library. Could you tell me how to implement
late binding for this library? Would I declare an object as the second
example above, and programmatically set the reference?
Any ideas,
Thanks, God bless
Van



"Bob Phillips" wrote:


"VanS" wrote in message
...
Bob,
Thanks for your reply and input.
My only concern-and I'm not positive this is a problem-is that I have
references to Excel (the app is on an Excel VBA platform), VB and I
removed
the Word 11.0 (I built on Office 2003) in order to use late-binding to
make
the app backward compatible for multiple platforms-back to Win
98/Office
97.
My concerns, if valid issues, are two-fold:
1. Might I lose references and functionality for later versions by
building
on an earlier platform (one reason I was using late binding).

You won't lose references, but you might lose functionality because the
later versions might not support that functionality. But irf you are
going
to deploy on an earlier version that functionality cannot be used
anyway, so
in reality you lose nothing.

2. I preferred building on my newer system for convenience. Might
there be
any other equally valid solutions?

Convenience maybe, but if you are going to deploy on an earlier version,
you
are opening yourself to the potential of it not working. The only sure
way
is to develop on the earliest version of software you intend to deploy
to.

You could use late binding if you are sure that you are not going to use
any
newly introduced functionality, but it will mean a full re-test on the
earlier versions to be sure.


Bob