Early vs Late Binding - Final Exam

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Early Binding vs Late Binding

After spending a great deal of time on this topic I thought I had a handle
on it, but in review I find myself as confused as I ever was. I have read so
many conflicting writeups that I am at a loss. So let me describe what I am
doing and please someone set me straight!

I have an Access 2003 app that automates with Word, Excel, and Outlook. I
have deemed that Office 2000 is my minimum but I want it to work well with
Office XP, Office 2003 and upward for the foreseeable future. The app will be
loaded with 2003 runtime if required. For sake of this discussion let’s focus
on Word however I use a similar approach all three.

In my VBA, I reference Microsoft Word 9.0 object library (Word 2000). In my
code when I use

Private objWordApp As Word.Application

The reason I don’t use “As Object†is because I want to reference some word
constants such as Word.Range, Word.Table, objwordapp.wdOpenFormatAuto. I am
happy to define these myself but I would need someone to point the way on how
to do this.

Set objWordApp = GetObject("", "Word.Application")

I have tested this on all platforms available ie. Office 2000, Office XP,
and Office 2003 and it all seems to work just fine. The question being, am
I using early binding, late binding, or some convoluted methodology of both?
Is there a downside to my approach? I don’t really care what approach I use
so long as it works on all platforms specified.

Help Mr.(or Ms.) Wizard – Help Me Please!
 
Rick Roberts said:
Early Binding vs Late Binding

After spending a great deal of time on this topic I thought I had a handle
on it, but in review I find myself as confused as I ever was. I have read
so
many conflicting writeups that I am at a loss. So let me describe what I
am
doing and please someone set me straight!

I have an Access 2003 app that automates with Word, Excel, and Outlook. I
have deemed that Office 2000 is my minimum but I want it to work well with
Office XP, Office 2003 and upward for the foreseeable future. The app will
be
loaded with 2003 runtime if required. For sake of this discussion let's
focus
on Word however I use a similar approach all three.

In my VBA, I reference Microsoft Word 9.0 object library (Word 2000). In
my
code when I use

Private objWordApp As Word.Application

The reason I don't use "As Object" is because I want to reference some
word
constants such as Word.Range, Word.Table, objwordapp.wdOpenFormatAuto. I
am
happy to define these myself but I would need someone to point the way on
how
to do this.

Set objWordApp = GetObject("", "Word.Application")

I have tested this on all platforms available ie. Office 2000, Office XP,
and Office 2003 and it all seems to work just fine. The question being,
am
I using early binding, late binding, or some convoluted methodology of
both?
Is there a downside to my approach? I don't really care what approach I
use
so long as it works on all platforms specified.

Help Mr.(or Ms.) Wizard - Help Me Please!
Click to expand...



As you are developing your application, it helps you as a programmer to use
early binding. That is, you write Dim wdApp As Word.Application. Then your
code editor will automatically list the methods and properties associated
with that object, for example you can see that wdApp.Quit is listed and with
abit of luck you may even be able to get the relavant help for this item.
Once you have finished testing, you should then switch from early to late
binding to avoid reference problems with different versions of Word. You do
this by removing the reference to the Word object library. However, as soon
as you do this, you cannot compile your code since Word.Application is not
understood and you have to use object - in fact I use an apostrophe to leave
in as a comment what the object should be. E.g.
Dim wdApp As Object 'Word.Application
The next problem will be that you can no longer use Set wdApp=New
Word.Application and have to change this to the GetObject or CreateObject,
depending on whether or not Word is already running (that is a slightly
separate topic and often involves error-handling). The final part is
altering the constants, because once you have removed the reference, the
compiler can no longer work out what, for example, wdColorGreen is supposed
to mean. So instead of writing
wdTable.Borders.InsideColor=wdColorGreen
you have to write:
wdTable.Borders.InsideColor=32768

or, define your own constants to make it easier to understand:

Const word_wdColorGreen=32768
wdTable.Borders.InsideColor=word_wdColorGreen
 
Thanks for responding. I understand the differences (I Think) but my dilema
remains. All developers seem to be of the same opinion that the best bet is
late binding.

My app is using MS Office Word, Excel and Outlook and my goal is to be
compatible with Office 2000, Office XP, Office 2003 and upward.

If I make my reference to the Office 2000 libraries and use early binding
what exactly am I losing? What risk am I taking? I have tested this on all
3 platforms (independently) and it seems to work flawlessly.

Obviously I cannot make any reference to anything new to XP or 2003 but
what else am I missing?
 
Rick Roberts said:
Thanks for responding. I understand the differences (I Think) but my
dilema
remains. All developers seem to be of the same opinion that the best bet
is
late binding.

My app is using MS Office Word, Excel and Outlook and my goal is to be
compatible with Office 2000, Office XP, Office 2003 and upward.

If I make my reference to the Office 2000 libraries and use early binding
what exactly am I losing? What risk am I taking? I have tested this on
all
3 platforms (independently) and it seems to work flawlessly.

Obviously I cannot make any reference to anything new to XP or 2003 but
what else am I missing?
Click to expand...


The risk is that you would end up with an Access application with broken or
missing references. For example, you develop the App with Office XP and
create references to the XP (version 10) object library and take it to a
machine with Office 2000 on it. When you view the code on that machine, you
find it is decompiled and that in the references section you have 'missing'
next to, say, Microsoft Word 10.0 Object Library.

As soon as you have missing references and uncompiled code, all sorts of
weird and wonderful errors start to appear such as ordinary VBA functions
like Len(MyString) being no longer recognised. Your whole project then
becomes completely unreliable with queries, forms, reports, etc all at risk.
Of course if the Office 2000 user is able to, he can simply open the
references, correct any missing ones to the appropriate version, and
recompile the code and everything will work again. But that is not always
practical/possible.

If you have heard that developer's recommend late binding, then you could
simply accept that it must be true and follow suit. I also would recommend
developing using early binding and switch to late binding before
distribution and this is based on seeing it all go wrong. You claim that
your code does not suffer from this and you have proved so, but I wonder how
thorough your testing has been. Have you taken it from 2000 to XP as well
as from XP to 2000? On both occasions were your references automagically
corrected? Did your code stay compiled? Please let us know.
 
If you have heard that developer's recommend late binding, then you could
simply accept that it must be true and follow suit. I also would recommend
developing using early binding and switch to late binding before
distribution and this is based on seeing it all go wrong. You claim that
your code does not suffer from this and you have proved so, but I wonder how
thorough your testing has been. Have you taken it from 2000 to XP as well
as from XP to 2000? On both occasions were your references automagically
corrected? Did your code stay compiled? Please let us know.
Click to expand...

Hi Stefan,

I got into this mess originally because of the broken/missing libraries.
This was back in the days when I was naively unaware of late binding vs.
early binding. I was referencing the 2003 office libraries and as soon as I
moved it to a platform of either Office 2000 or XP it blew up.

Since then I have read, played, and tested the subject rather extensively.
What I have come across is referencing the 2000 libraries in the 2003
version. They are upwardly compatible meaning the XP and 2003 will run just
fine referencing the 2000 libraries. In my startup code I check to make sure
that all reference libraries for “isbroken†All are present and accounted
for.

As far as testing I have performed the following:
All works just fine on the development machine using a Windows XP Pro +
Office 2003 platform. From there I created an MDE, using Access 2003 with the
2000 library references. Then using a PC that had Windows 2000 + Office 2000
(Word, Excel, Outlook only) and loaded the MDE and Access 2003 Runtime. It
automates all 3 applications just fine. From there I tested on a Windows XP +
Office XP using the same MDE file. Again all was good.

Being an MDE I don’t think it can decompile, it just blows!

Until I find a reason I can’t, I am going to stick with this methodology. As
I stated before I understand that I can’t call any new features rolled out
with Office XP or 2003 but I haven’t come across any new features that I
couldn’t live without.

I hope this helps some people out there that run across the same issues!

Libraries referenced:
Msword9.olb
Msoutl9.olb
Msword9.olb
 
Checking for 'isbroken' at startup is worthless in an mde:
your application will just fail with meaningless messages
if you try to run on a machine where Outlook is missing
or incorrectly registered.

For some people, this is an important issue.

Incidentally, you started the discussion by saying:
The reason I don’t use “As Object†is because
I want to reference some word constants such as Word.Range,
Word.Table, objwordapp.wdOpenFormatAuto. I am
Click to expand...

Now that you know how to do that, you can implement the
change if you wish. As with any development, you will
have to make your own decision if the extra work is justified
for your users.


(david)
 
Hi Rick,

One thing you need to be aware of. Going from Office 2002 (XP) to
Office 2003 all Office specific references are promoted from Version 10
to Version 11. However when you develop under Office 2003 and then
attempt to use Office 2002 NOT all the Office specific references are
demoted back to Version 10.

One clear example is to write VBA code using early binding in Excel
2003 referencing Word 2003. Now attempt to run that code in Office
2002. You will get eractic errors that do not make sense. This is
because if you check your references you will find that every Office
library automatically demoted back to Version 10... EXCEPT for Word
2002 which remained as Version 11. And as such Office marked this
reference as "MISSING:".

The same happens in the opposite direction using Word 2003 and
referencing Excel 2003 and then attempting to run the code in Office
2002.

I have been told that "early" binding is much faster and recommended
(not to mention a lot easier to work with) if all your users are
working from the same version of Office. BUT as in your case and mine
as well as most. Different shops use different tools. Which means you
are taking a great risk in NOT using "late" binding.

In my view this is a bug in Office, but until it gets fixed our choice
is clear.


Jamie
 
Back
Top