View Single Post
  #6   Report Post  
Posted to microsoft.public.excel.programming
Bob Phillips[_6_] Bob Phillips[_6_] is offline
external usenet poster
 
Posts: 11,272
Default EARLY binding or LATE binding ?

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