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.