Hello,
I have a vb6/Excel/Word vba app which I develop in Win xp pro and Office
2003. It uses a reference to the MS VBA Extensibility 5.3 library
(vbe6ext.olb). But when I install and run to test under a Virtual PC Win 98
Office 97 testbed, it seems to lose the reference and bombs out as it looks
for it. The 5.3 is supposed to replace earlier versions and be backward
compatible as I understand.
Does anyone know if there is something I need to do in the installer app, or
have any suggestions on how to get it to point to the correct location? Did I
need to add it to the installer app? I need to make the app and install work
on multiple OS and Office platforms.
Thanks, God bless,
Van

Build it on the older system and then migrate to the later version.

--

HTH

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


"VanS" wrote in message
...
Hello,
I have a vb6/Excel/Word vba app which I develop in Win xp pro and Office
2003. It uses a reference to the MS VBA Extensibility 5.3 library
(vbe6ext.olb). But when I install and run to test under a Virtual PC Win
98
Office 97 testbed, it seems to lose the reference and bombs out as it
looks
for it. The 5.3 is supposed to replace earlier versions and be backward
compatible as I understand.
Does anyone know if there is something I need to do in the installer app,
or
have any suggestions on how to get it to point to the correct location?
Did I
need to add it to the installer app? I need to make the app and install
work
on multiple OS and Office platforms.
Thanks, God bless,
Van

Backward compatible means it will run code built in older versions. Older
versions won't run code built in newer verions and is the problem you are
encountering. See Bob's answser.

--
Regards,
Tom Ogilvy

"VanS" wrote in message
...
Hello,
I have a vb6/Excel/Word vba app which I develop in Win xp pro and Office
2003. It uses a reference to the MS VBA Extensibility 5.3 library
(vbe6ext.olb). But when I install and run to test under a Virtual PC Win
98
Office 97 testbed, it seems to lose the reference and bombs out as it
looks
for it. The 5.3 is supposed to replace earlier versions and be backward
compatible as I understand.
Does anyone know if there is something I need to do in the installer app,
or
have any suggestions on how to get it to point to the correct location?
Did I
need to add it to the installer app? I need to make the app and install
work
on multiple OS and Office platforms.
Thanks, God bless,
Van

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).
2. I preferred building on my newer system for convenience. Might there be
any other equally valid solutions?
Thanks, God bless,
Van

"Bob Phillips" wrote:

Build it on the older system and then migrate to the later version.

--

HTH

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


"VanS" wrote in message
...
Hello,
I have a vb6/Excel/Word vba app which I develop in Win xp pro and Office
2003. It uses a reference to the MS VBA Extensibility 5.3 library
(vbe6ext.olb). But when I install and run to test under a Virtual PC Win
98
Office 97 testbed, it seems to lose the reference and bombs out as it
looks
for it. The 5.3 is supposed to replace earlier versions and be backward
compatible as I understand.
Does anyone know if there is something I need to do in the installer app,
or
have any suggestions on how to get it to point to the correct location?
Did I
need to add it to the installer app? I need to make the app and install
work
on multiple OS and Office platforms.
Thanks, God bless,
Van

Tom,
I am replying to you and Bob both on this so hope I am not being
unnecessarily redundant.
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).
2. I preferred building on my newer system for convenience. Might there be
any other equally valid solutions?
Thanks, God bless,
Van


"Tom Ogilvy" wrote:

Backward compatible means it will run code built in older versions. Older
versions won't run code built in newer verions and is the problem you are
encountering. See Bob's answser.

--
Regards,
Tom Ogilvy

"VanS" wrote in message
...
Hello,
I have a vb6/Excel/Word vba app which I develop in Win xp pro and Office
2003. It uses a reference to the MS VBA Extensibility 5.3 library
(vbe6ext.olb). But when I install and run to test under a Virtual PC Win
98
Office 97 testbed, it seems to lose the reference and bombs out as it
looks
for it. The 5.3 is supposed to replace earlier versions and be backward
compatible as I understand.
Does anyone know if there is something I need to do in the installer app,
or
have any suggestions on how to get it to point to the correct location?
Did I
need to add it to the installer app? I need to make the app and install
work
on multiple OS and Office platforms.
Thanks, God bless,
Van

"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

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

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