What’s the difference between thesr

[shilpa]

1. What's the difference between early binding and late binding ?

[lucky_kk20]

i m not sure but tht wht i know...............


early binding is done at compile time and late binding is done at run time

[BINNY]

HI,

lucky_kk20 you are absolutely correct ...

Early binding is done during Compile time .
Late binding is done during Run time .

[Hemanth_2u]

What is Binding?

Binding is a process of matching function calls written by the programmer to the actual code (internal or external) that implements the function. It is done when the application is compiled, and all functions called in code must be bound before the code can be executed.

To understand the process, think of "binding" in terms of publishing a book. Imagine your code is like the text of the book where in a certain paragraph you have written something like "see chapter 12, page x for more details." You don't know what the page number is until the book is finished, so before the paragraph can be read as intended, all the pages of the book must be bound together and the correct page number inserted into the paragraph. You wait for the book to be "bound" before you can reference other parts of the book.

Binding software is similar. Your code is made up of parts that need to be pulled together before the code can be "read." Binding is the act of replacing function names with memory addresses (or memory offsets, to be more precise) where the code will "jump to" when the function is called. For COM objects, the address is a memory offset in a table of pointers (called the v-table) held by the object. When a COM function is bound, it is bound through the v-table.

The structure of a COM object is simple. When your code holds a reference to an object, it holds an indirect pointer to the top of the v-table. The v-table is an array of memory addresses where each entry is a different function that can be called on that object. To call the third function on a COM object, you jump down three entries in the table and then jump to the memory location given there. That executes the code for the function and, when complete, returns you back ready to execute the next line of code. +-[Code]------------+ +.................................[COM Object]...+
| | : +-------------+ :
|Set obj = Nothing -|--->| obj pointer | :
| | : +-|-----------+ :
+-------------------+ : | +-----------------+ :
: +-->| v-table pointer | :
: +--|--------------+ :
: | :
: | +----------------------------+ :
: (3rd) | | Function 1 Address pointer | :
: (Offset) | +----------------------------+ :
: | | Function 2 Address pointer | :
: | +----------------------------+ :
: +->| Function 3 Address pointer | :
: +----------------------------+ :
+................................................+

The example above shows what happens when releasing a COM object. Because all COM objects inherit from IUnknown, the first three entries in the table are the methods to IUnknown. When you need to free an object, your code calls the third function in the v-table (IUnknown::Release).

Fortunately, this work is done by Visual Basic behind the scenes. As a Visual Basic programmer, you never have to deal with a v-table directly. But, this structure is how all COM objects are bound, and it is important that you are familiar with it to understand what binding is.

Early Binding

The example above is what is known as early (or v-table) binding. For all COM objects, this form of binding takes place whenever a COM object's IUnknown interface is called. But what about the other functions of the object? How do you call its Refresh method or its Parent property? These are custom functions that are typically unique to an object. If their locations in the v-table cannot be assumed, how do you find the function addresses needed to call them?

The answer, of course, depends on whether or not you know in advance what the object's v-table looks like. If you do, you can perform the same early-binding process to the object's custom methods as you did to its IUnknown methods. This is what is generally meant by "early-binding."

To use early binding on an object, you need to know what its v-table looks like. In Visual Basic, you can do this by adding a reference to a type library that describes the object, its interface (v-table), and all the functions that can be called on the object. Once that is done, you can declare an object as being a certain type, then set and use that object using the v-table. For example, if you wanted to Automate Microsoft Excel using early binding, you would add a reference to the "Microsoft Excel 8.0 Object Library" from the Project|References dialog, and then declare your variable as being of the type "Excel.Application." From then on, all calls made to your object variable would be early bound: ' Set reference to 'Microsoft Excel 8.0 Object Library' in
' the Project|References dialog (or Tools|References for VB4 or VBA).

' Declare the object as an early-bound object
Dim oExcel As Excel.Application

Set oExcel = CreateObject("Excel.Application")

' The Visible property is called via the v-table
oExcel.Visible = True
This method works great most of the time, but what if you don't know the exact object you will be using at design time? For example, what if you need to talk to multiple versions of Excel, or possibly to an "unknown" object altogether?

Late Binding

COM includes IDispatch. Objects that implement IDispatch are said to have a dispinterface (if it is the only interface they support) or dual interface (if they also have a custom interface that you can early bind to). Clients that bind to IDispatch are said to be "late bound" because the exact property or method they are calling is determined at run time using the methods of IDispatch to locate them. Going back to the book example earlier, think of it as being like a footnote that directs you to the table of contents where you have to "look up" the page number at "read time" rather than having it already printed there in the text.

The magic of the interface is controlled by two functions: GetIDsOfNames and Invoke. The first maps function names (strings) to an identifier (called a dispid) that represents the function. Once you know the ID for the function you want to call, you can call it using the Invoke function. This form of method invocation is called "late binding."

Again, in Visual Basic the way you specify how the object is bound is by your object declaration. If you declare an object variable as "Object" you are, in fact, telling Visual Basic to use IDispatch, and are therefore late binding: ' No reference to a type library is needed to use late binding.
' As long as the object supports IDispatch, the method can
' be dynamically located and invoked at run-time.

' Declare the object as a late-bound object
Dim oExcel As Object

Set oExcel = CreateObject("Excel.Application")

' The Visible property is called via IDispatch
oExcel.Visible = True
As you can see, the rest of your code is the same. The only difference between early binding and late binding (in terms of the code you write) is in the variable declaration.

It is important to note that what is "late bound" is the function being called and not the way it is called. From the earlier discussion on binding in general, you should notice that IDispatch itself is "early bound:" that is to say that Visual Basic makes the call to set the Visible property through a v-table entry (IDispatch::Invoke) as it would any COM call. The COM object itself is responsible for forwarding the call to the correct function to make Excel visible. This indirection allows the Visual Basic client to be compiled (that is, bound to a valid function address) but still not know the exact function that will actually do the work.

[lokanath]

when a method call is linked with method body at the compile time then it is called early binding.if it is linked at the run time then it is called latebinding .

[meera]

Early vs. Late Binding There are two ways to use Automation (or OLE Automation) to programmatically control another application. Late binding uses CreateObject to create and instance of the application object, which you can then control. For example, to create a new instance of Excel using late binding: Dim oXL As Object Set oXL = CreateObject("Excel.Application") On the other hand, to manipulate an existing instance of Excel (if Excel is already open) you would use GetObject (regardless whether you're using early or late binding): Dim oXL As Object Set oXL = GetObject(, "Excel.Application") To use early binding, you first need to set a reference in your project to the application you want to manipulate. In the VB Editor of any Office application, or in VB itself, you do this by selecting Tools + References, and selecting the application you want from the list (e.g. “Microsoft Excel 8.0 Object Library”). To create a new instance of Excel using early binding: Dim oXL As Excel.Application Set oXL = New Excel.Application In either case, incidentally, you can first try to get an existing instance of Excel, and if that returns an error, you can create a new instance in your error handler. Advantages of Early Binding Your code will run considerably faster, because it can all be compiled up front. With late binding, the code relating to an application you declared as an object has to, in effect, be compiled as it runs. Because your code can all be compiled up front, debugging is far easier – select Debug + Compile, and the compiler will be able to spot syntax errors which would have been missed had you used late binding. You have full access in your project to intellisense (type a keyword and a dot to get a popup list of properties and methods supported by that keyword, select one to insert it; type a keyword and press F1 to launch the Help topic on that keyword). You have full access to the application's object model via the Object Browser and VBA Help. You have access to the application's built-in constants. For instance, if you are automating Word from Excel, you can use: Dim objWord As Word.Application Set objWord = New Word.Application With objWord .Visible = True .Activate .WindowState = wdWindowStateMaximize .Documents.Open ("c:\temp\temp.doc") End With Furthermore, when you type .WindowState = you'll get a pop-up list of the supported constants, and can simply pick “wdWindowStateMaximize” from the list. If you used late binding, you would need to use: .WindowState = 1 .. and you would need to know (by looking it up in Word's Object Browser) that the value of the constant “wdWindowStateMaximize” happens to be 1. All this makes programming using early binding immeasurably easier than using late binding. Advantages of Late Binding The main advantage is that code which uses late binding is more certain to be version-independent If you set a reference in a Word 97 project to “Microsoft Excel 8.0 Object Library”, then the project will run OK on a machine which has Office 2000 installed. Word 2000 changes the reference on the fly to the “Microsoft Excel 9.0 Object Library”. But as they famously say, YMMV. Problems have been found in certain circumstances. For instance, if you run a Word 97 project containing a reference to the Excel 8.0 object library on a machine with Office 2000 installed, it will run OK, but you may get the occasional “cannot open macro storage” error unless you save the project in Word 2000. If you do save it in Word 2000, the reference will change to the Excel 9.0 object library. So if you use early binding and support a mixed environment, it may be safest to create separate Word 97 and Word 2000 versions of your addins, despite the maintenance overhead. The more references your project contains, the larger the file size and the longer it takes to compile. Some programming environments don't allow you to create references to another application. Summary Personally, as someone who finds programming difficult at the best of times, I would never dream of using late binding – why make life harder for yourself than it has to be? But some programming geniuses prefer to use late binding, because of the peace of mind it gives them regarding version independence – or maybe some of them just enjoy the challenge! <g> But you pays your money and makes your choice ... To those unfortunate souls using programming environments in which you have to use late binding, all I can say is: Look on the bright side – you could have ended up as an Assembly language programmer ...