I've been in de Bruin's website and he recommends (for binding Outlook
from inside Excel) using early binding first, because its easier to
write code with, and then to switch your code to late binding, as
it'll stand the test of time better

A friend at work understands late binding but swears by early binding

Any opinions - or can both be advantageous in different situations?

Jason

"jason" wrote in message
om...
I've been in de Bruin's website and he recommends (for binding Outlook
from inside Excel) using early binding first, because its easier to
write code with, and then to switch your code to late binding, as
it'll stand the test of time better

A friend at work understands late binding but swears by early binding

Any opinions - or can both be advantageous in different situations?


Early binding generally provides better performance since the
type information is provided to the object code by the compiler.
With late binding the system has to make extra calls at run time
to get the type iformation for error checking etc.

The major advantage of late binding is that it allows
you to pass an argument choosing which type of object
to bind to. This is advantageous if there is more
than object which has similar methods and properties
and you need to select one or other at run time.

Keith

Jason,

There are advantages and disadvantages to both. Intellectually, or perhaps
theoretically, I come down on the side of Early binding, practically I go
the other way.

Take a look at this recent discussion on the topic. It answers a question on
CreateObject against New, but as these are intrinsically tied to late vs.
early binding, that is what is really discussed.

http://tinyurl.com/2ay78

And here is a previous post of mine on how to go about the approach that Ron
discusses, so you will get an idea of the overhead

http://tinyurl.com/2qern

--

HTH

Bob Phillips
... looking out across Poole Harbour to the Purbecks
(remove nothere from the email address if mailing direct)

"jason" wrote in message
om...
I've been in de Bruin's website and he recommends (for binding Outlook
from inside Excel) using early binding first, because its easier to
write code with, and then to switch your code to late binding, as
it'll stand the test of time better

A friend at work understands late binding but swears by early binding

Any opinions - or can both be advantageous in different situations?

Jason

In my opinion
The primary advantage of late binding in an application which you are
distributing to other users is that you won't get an error if they have a
different reference of the object library than you used to develop the app.
(if you use arguments not available to their version you will still have
problems - but that is a challenge you should meet).

If you can be assured this will not be a problem, then early binding offers
the fastest performance.

here is some additional information:

http://support.microsoft.com/default...b;EN-US;244167
INFO: Writing Automation Clients for Multiple Office Versions

http://support.microsoft.com/default...b;en-us;245115
INFO: Using Early Binding and Late Binding in Automation

http://support.microsoft.com/default...b;en-us;247579
INFO: Use DISPID Binding to Automate Office Applications Whenever Possible

Address some of the issues.

--
Regards,
Tom Ogilvy

"jason" wrote in message
om...
I've been in de Bruin's website and he recommends (for binding Outlook
from inside Excel) using early binding first, because its easier to
write code with, and then to switch your code to late binding, as
it'll stand the test of time better

A friend at work understands late binding but swears by early binding

Any opinions - or can both be advantageous in different situations?

Jason

You've received some good tips already. IMO, there are two very good
reasons for using only late binding in a final product but using early
binding during development.

Early binding enables the use of VBE's Intellisense capability, which I
consider invaluable.

However, early binding allows for the introduction of a possible bug
where one can make an unqualified reference to the automated object
creating a 'behind the scenes' link between the caller and the callee
(is there such a word?). Testing with late binding will catch such
links. See the Excel/VBA/'Program won't quit' page of my site for
more.

The other problem with early binding is that the use of set
xlApp=Excel.Application initiates XL if it is not running. That's bad
enough since I don't know if I started the automated task or not. But,
worse, now there is that 'behind the scenes' link between the calling
program used to run the code and the callee.

I haven't seen how Ron manages late and early binding, but in my case I
use a compiler-directive.

Option Explicit

#Const EarlyBind = True

Sub testIt()
#If EarlyBind Then
Dim xlApp As Excel.Application
#Else
Dim xlApp As Object
#End If
Dim IStartedXL As Boolean
'...
On Error Resume Next
#If EarlyBind Then
Set xlApp = Excel.Application
If xlApp Is Nothing Then 'Never true :(
Set xlApp = New Excel.Application
IStartedXL = True
End If
#Else
Set xlApp = GetObject(, "excel.application")
If xlApp Is Nothing Then
Set xlApp = CreateObject("excel.application")
IStartedXL = True
End If
#End If
On Error GoTo 0
'...
If IStartedXL Then
xlApp.Quit
End If
Set xlApp = Nothing
End Sub


--
Regards,

Tushar Mehta
www.tushar-mehta.com
Excel, PowerPoint, and VBA add-ins, tutorials
Custom MS Office productivity solutions

In article ,
says...
I've been in de Bruin's website and he recommends (for binding Outlook
from inside Excel) using early binding first, because its easier to
write code with, and then to switch your code to late binding, as
it'll stand the test of time better

A friend at work understands late binding but swears by early binding

Any opinions - or can both be advantageous in different situations?

Jason

Tushar,

I think Ron was, and certainly what I describe in the link I provided, is
developing using early binding and identifying any constants. For instance,
this line in Outlook
Set objMailItem = objOutlook.CreateItem(olMailItem)
needs the value of constant olMailItem, which can easily be ascertained by
typing ?olMailItem in the immediate window , and substitute it's value in
the code for it's late bound production version.

I personally don't use the technique that you show, although I appreciate
it's merits and strengths, on the basis that it makes the code very much
more difficult to read, and therefore to debug when there is a logic flaw.

--

HTH

Bob Phillips
... looking out across Poole Harbour to the Purbecks
(remove nothere from the email address if mailing direct)

"Tushar Mehta" wrote in message
news:MPG.1aa7c963650879d6989714@news-server...
You've received some good tips already. IMO, there are two very good
reasons for using only late binding in a final product but using early
binding during development.

Early binding enables the use of VBE's Intellisense capability, which I
consider invaluable.

However, early binding allows for the introduction of a possible bug
where one can make an unqualified reference to the automated object
creating a 'behind the scenes' link between the caller and the callee
(is there such a word?). Testing with late binding will catch such
links. See the Excel/VBA/'Program won't quit' page of my site for
more.

The other problem with early binding is that the use of set
xlApp=Excel.Application initiates XL if it is not running. That's bad
enough since I don't know if I started the automated task or not. But,
worse, now there is that 'behind the scenes' link between the calling
program used to run the code and the callee.

I haven't seen how Ron manages late and early binding, but in my case I
use a compiler-directive.

Option Explicit

#Const EarlyBind = True

Sub testIt()
#If EarlyBind Then
Dim xlApp As Excel.Application
#Else
Dim xlApp As Object
#End If
Dim IStartedXL As Boolean
'...
On Error Resume Next
#If EarlyBind Then
Set xlApp = Excel.Application
If xlApp Is Nothing Then 'Never true :(
Set xlApp = New Excel.Application
IStartedXL = True
End If
#Else
Set xlApp = GetObject(, "excel.application")
If xlApp Is Nothing Then
Set xlApp = CreateObject("excel.application")
IStartedXL = True
End If
#End If
On Error GoTo 0
'...
If IStartedXL Then
xlApp.Quit
End If
Set xlApp = Nothing
End Sub


--
Regards,

Tushar Mehta
www.tushar-mehta.com
Excel, PowerPoint, and VBA add-ins, tutorials
Custom MS Office productivity solutions

In article ,
says...
I've been in de Bruin's website and he recommends (for binding Outlook
from inside Excel) using early binding first, because its easier to
write code with, and then to switch your code to late binding, as
it'll stand the test of time better

A friend at work understands late binding but swears by early binding

Any opinions - or can both be advantageous in different situations?

Jason

In article ,
says...

Set objMailItem = objOutlook.CreateItem(olMailItem)
needs the value of constant olMailItem, which can easily be ascertained by
typing ?olMailItem in the immediate window , and substitute it's value in
the code for it's late bound production version.

No, I would use it as a constant defined in the code conditionally
compiled for late-binding. That way the rest of the code remains
*unchanged.*


I personally don't use the technique that you show, although I appreciate
it's merits and strengths, on the basis that it makes the code very much
more difficult to read, and therefore to debug when there is a logic flaw.

I don't understand this. Only the initialization and termination of
the automated object is subject to conditional compilation. Together
with the conditionally compiled late-bound run time constants that
complement the early-bind mnemonics, the rest of the code -- the code
that does the actual work -- remains unchanged! In fact, instead of
making things difficult, the approach significantly strengthens the
ability to write correct code. Maybe, this slightly reorganized and
minimally-documented code will illustrate the idea better.

Option Explicit

#Const EarlyBind = True

Sub testIt()
'Automation management code. Leave alone. There is _
nothing here that has any functional responsibility
Dim IStartedOL As Boolean
On Error Resume Next
#If EarlyBind Then
Dim objOLApp As Outlook.Application
Set objOLApp = Outlook.Application
If objOLApp Is Nothing Then 'Never true :(
Set objOLApp = New Outlook.Application
IStartedOL = True
End If
#Else
Dim objOLApp As Object
Set objOLApp = GetObject(, "outlook.application")
If objOLApp Is Nothing Then
Set objOLApp = CreateObject("outlook.application")
IStartedOL = True
End If
#End If
On Error GoTo 0
'End automation management code
'
'Functional declarations related to automation object. _
Only declarations go in this section
#If EarlyBind Then
Dim objMailItem(1 To 10) As Outlook.MailItem
#Else
Dim objMailItem(1 To 10) As Object
'For late-bound code, add constants to complement _
OL mnemonics here
Const olMailItem As Integer = 0, _
olContactItem As Integer = 2
#End If
'End automation-related functional declarations

'...
'Functional code goes here. Note that it is completely _
insensitive to how it is compiled!
Dim i As Integer
For i = LBound(objMailItem) To UBound(objMailItem)
Set objMailItem(i) = objOLApp.CreateItem(olMailItem)
Next i
'...
'Other functional code
'...
For i = LBound(objMailItem) To UBound(objMailItem)
objMailItem(i).Delete
Set objMailItem(i) = Nothing
Next i
'...
'More functional code
'...

'Automation management code
If IStartedOL Then
objOLApp.Quit
End If
Set objOLApp = Nothing
End Sub

--
Regards,

Tushar Mehta
www.tushar-mehta.com
Excel, PowerPoint, and VBA add-ins, tutorials
Custom MS Office productivity solutions

In article ,
says...
Tushar,

I think Ron was, and certainly what I describe in the link I provided, is
developing using early binding and identifying any constants. For instance,
this line in Outlook
Set objMailItem = objOutlook.CreateItem(olMailItem)
needs the value of constant olMailItem, which can easily be ascertained by
typing ?olMailItem in the immediate window , and substitute it's value in
the code for it's late bound production version.

I personally don't use the technique that you show, although I appreciate
it's merits and strengths, on the basis that it makes the code very much
more difficult to read, and therefore to debug when there is a logic flaw.