Early or Late binding.

I'v seen different manners of creating objects and some use late and early in same function (my opinion).

So can someone tell me what is early and what is late from the following examles.

VB Code:

Dim myC As MyCls.MyFun
Set myC = CreateObject("MyCls.MyFun")
 
Dim myC As MyCls.MyFun
Set myC = New MyCls.MyFun
 
Dim myC As Object
Set myC = CreateObject("MyCls.MyFun")

Once you refernce the DLL from project - > references, its all early binding, does not matter how you use it.

For these two to work, you will have to reference the MyCls from references. this is called early binding
--------------------------------------------------------------------------------
Dim myC As MyCls.MyFun
Set myC = CreateObject("MyCls.MyFun")

Dim myC As MyCls.MyFun
Set myC = New MyCls.MyFun
--------------------------------------------------------------------------------

while this will work even if you do not reference the MyCls from references. this is called late binding. However, even with this style if you reference MyCls from Project - > References it will be early binding then.
--------------------------------------------------------------------------------
Dim myC As Object
Set myC = CreateObject("MyCls.MyFun")
--------------------------------------------------------------------------------

techyspecy is just a little off here. Early or late binding is a matter of how the object is declared. Not how it is created. If you declare an object variable of a specific class it is early bound.

VB Code:

Dim myC As MyCls.MyFun 'early bound

If the object is declared as a genric object, it is late bound.

VB Code:

Dim myC As Object 'late bound

In general, a early bound object runs faster and is more efficeint. Check into MSDN, there is a ton of info there on this subject.

To sum up the above two posts:

You have to set a reference to the DLL serving the objects inside your project. Also you have to declare an object variable to be of a specific class type than declaring simply as Object.

To add my own: It's believed to be faster if you use:

Code:

---

Dim MyObj As FunnyObject
Set MyObj = New FunnyObject

---

than this:

Code:

---

Dim MyObj As New FunnyObject

---

.

Quote:

---

Originally posted by MarkT
techyspecy is just a little off here. Early or late binding is a matter of how the object is declared. Not how it is created. If you declare an object variable of a specific class it is early bound.

VB Code:

Dim myC As MyCls.MyFun 'early bound

If the object is declared as a genric object, it is late bound.

VB Code:

Dim myC As Object 'late bound

In general, a early bound object runs faster and is more efficeint. Check into MSDN, there is a ton of info there on this subject.

---

Take my word pal, you are wrong.
As soon as you reference a DLL in your project its early binding. Becuase compiler already knows what bindings you are using.

Quote:

---

Originally posted by techyspecy
Take my word pal, you are wrong.
As soon as you reference a DLL in your project its early binding. Becuase compiler already knows what bindings you are using.

---

Pure late binding is when you do not reference the DLL in your project and use it in this manner :

dim a as object

set a = createobject("ADODB.Recordset")

this is late binding, cause compiler does not know in advance that ADO is referenced, only at a point when it encounters the createobject line it binds the ADO library dynamically to the project. and this is what is called late binding. Once you reference the Library then it does not matter how you create object off it. Its already packed up with your project and thus its called early binding. Declaring objects then becomes nothing more than a matter of choice. Some people use New some use CreateObject some still use Object Style. But it really does not matter after referencing the library. Sure there are some performace issue with each style.

Quote:

---

Originally posted by techyspecy
Take my word pal, you are wrong.
As soon as you reference a DLL in your project its early binding. Becuase compiler already knows what bindings you are using.

---

Straight form MSDN. Do a search for "Speeding Object References"

Quote:

---

Object references are early-bound if they use object variables declared as variables of a specific class. Object references are late-bound if they use object variables declared as variables of the generic Object class. Object references that use early-bound variables usually run faster than those that use late-bound variables.

For example, you could assign a reference to an Excel object to either of the following variables:

Dim xlApp1 As Excel.Application
Set xlApp1 = New Excel.Application

Dim xlApp2 As Object
Set xlApp2 = CreateObject("Excel.Application")

Code that uses variable xlApp1 is early-bound and will execute faster than code that uses variable xlApp2, which is late-bound.

---

Quote:

---

Originally posted by MarkT
Straight form MSDN. Do a search for "Speeding Object References"

---

Listen dude,

this is absolutely right, but it never says once you make a reference from project menu - > references and still declare them as object it will be late bound. Once you make a reference its done.

If you have a reference to Excel and you use this syntax

VB Code:

Dim xlApp2 As Object 
Set xlApp2 = CreateObject("Excel.Application")

It is not early bound because at compile time the xlApp2 object is not bound to any specific object. It is not until the set statement that the app know that xlApp2 it going to be bound to an Excel object.

The bottom line is if at compile time the object is not bound to a specific class then the object is going to be late bound.

In order for an object to be early bound you do need a reference set to it in your project but just setting a reference to it will not make it early bound.

I consider this as true late binding :)

VB Code:

Sub InvokeClientFunction(objClient As Object)
MsgBox objClient.GetARandomNumber
End Sub

Whereby you can pass any object as long as it has
GetARandomNumber function. Mostly used in interface inheritance,
whereby as a server, you've no idea in advance of what kind of
client is passed to you. Those clients may or may not inherit the
standard client interface as used by the server.

Quote:

---

Originally posted by jian2587
I consider this as true late binding :)

VB Code:

Sub InvokeClientFunction(objClient As Object)
MsgBox objClient.GetARandomNumber
End Sub

Whereby you can pass any object as long as it has
GetARandomNumber function. Mostly used in interface inheritance,
whereby as a server, you've no idea in advance of what kind of
client is passed to you. Those clients may or may not inherit the
standard client interface as used by the server.

---

This isn't my question and is certanly not an example of a late bound object.

The passed object can be a late or early bound object cause it is certanly bounded to a class before it enters this sub else you would get a object or with block not set error.

Way besides the question.

Here is an other MSDN quote. Found under CreateObject Function.

Quote:

---

Declaring an object variable with the As Object clause creates a variable that can contain a reference to any type of object. However, access to the object through that variable is late bound; that is, the binding occurs when your program is run. To create an object variable that results in early binding, that is, binding when the program is compiled, declare the object variable with a specific class ID. For example, you can declare and create the following Microsoft Excel references:

---

If you can find anywhere in MSDN that says that setting a reference to something in the project makes it early bound then please point me to where I can find it because that is against everything I know.

Quote:

---

Originally posted by techyspecy
Listen dude,

this is absolutely right, but it never says once you make a reference from project menu - > references and still declare them as object it will be late bound. Once you make a reference its done.

---

Ha you think so.

So if i set a refernce to word and to excel and i'll code it like

VB Code:

Dim obj As Object
 
If dudeAsks = "Excel" Then
   Set obj = CreateObject("Excel.Application")
Else
   Set obj = CreateObject("Word.Application")
End If

How could this be early bound , compiler won't know which class there will be used in this function.

If it would be a coding standard in the office to have early bound object you should need to set the dim statement in the If structure.

What will be done on compiling here then ??

You people do not get it, do you ?

If you set the reference and do this stuff, it won;t know the difference but at run time it will pick that reference automatically while in other case it will look into V-Table for the proper reference of the referenced class in your code.

early bound

VB Code:

Dim objEx As Excel.Application
   Dim objAc As Access.Application
   Dim objWo As Word.Application
   
   If dudeWants = "Excel" Then
      Set objEx = New Excel.Application
   ElseIf dudeWants = "Access" Then
      Set objAc = New Access.Application
   Else ' this dude needs word
      Set objWo = New Word.Application
   End If
   
   Set objEx = Nothing
   Set objWo = Nothing
   Set objAc = Nothing

late bound

VB Code:

Dim obj As Object
   
   If dudeWants = "Excel" Then
      Set obj = New Excel.Application
   ElseIf dudeWants = "Access" Then
      Set obj = New Access.Application
   Else ' this dude needs word
      Set obj = New Word.Application
   End If
   
   Set obj = Nothing

Quote:

---

Originally posted by swatty
This isn't my question and is certanly not an example of a late bound object.

The passed object can be a late or early bound object cause it is certanly bounded to a class before it enters this sub else you would get a object or with block not set error.

Way besides the question.

---

Look, just an example, if we're to check out if it's any particular
object we can with TypeOf but I know that's not the point
here. What I mean is, the passed object from the client to the
server is definitely an object not recognized by the server, but the
server knows what it wants to invoke. If the client doesn't
support the invoketion, well u know wut happens, but that's not
the point. So since the server doesn't recognize the object yet it
invokes a function of the object which it doesn't know in advance
of wether it is legal or valid or not. This is really a late-binding.
During this stage, the program performs some trickery here,
resulting in slow performance if u're to use late-binding.

Quote:

---

Originally posted by techyspecy
You people do not get it, do you ?

If you set the reference and do this stuff, it won;t know the difference but at run time it will pick that reference automatically while in other case it will look into V-Table for the proper reference of the referenced class in your code.

---

Sure you don't

binding happens at compile time , your program is compiled before it is run.

If the class type isn't known at compile time it will bind it at runtime so it is late bound.

If it can pick up that reference or not it is late if it needs to be done at runtime.

Why do people write early bounded objects with createobject instead of New

VB Code:

' i find this funny coding when you have the reference set already
Dim myC As MyCls.MyFun
Set myC = CreateObject("MyCls.MyFun")
 
'if you use early binding then this is my approach
Dim myC As MyCls.MyFun
Set myC = New MyCls.MyFun

Hehe that's a pretty question
I favor New instead of CreateObject
eventhough both perform same stuffs but at some point, the
decision of choosing between these two will change the control-
flow of the program altogether. Not sure about this, I guess it's
something "portrayed" in an example I downloaded which
involves multi-threading using ActiveX exe. I see that the author
writes CreateObject instead of New when he/she wants to create
a new object running in its own thread. Perhaps if using New
the thing will run in its parent thread instead.

Correct me if I'm wrong.

Quote:

---

Originally posted by techyspecy
You people do not get it, do you ?

If you set the reference and do this stuff, it won;t know the difference but at run time it will pick that reference automatically while in other case it will look into V-Table for the proper reference of the referenced class in your code.

---

Unless you declare an object variable as a specific type, it is not early bound.

VB's compiler isn't so smart, ya see. Here's an example as to why:

Dim X As Blah
Set X = New Blah

^^^ This is faster than

Dim X As New Blah

The reason being, in the second instance the compiler isn't smart enough to know the life cycle of the object (X), so every time it is referenced it has to see if it has been instantiated. This is not the case in the first instance.

Just a bit of trivia for the day. ;)

When you declare a variable as Object, Variant, Form or Control, Visual Basic cannot determine at compile time what sort of object reference the variable will contain. There for VB must use 'late binding' to determine at 'run time' whether the actual object has properties and methods you call using that variable.

You are forcing the 'GetIDsOfNames' method in the IDispatch interface to return the DispID for that given member name.

Whether you reference the library or not doesn't matter. If you don't use the referenced library, VB uses late binding to make the proper calls to run the program.