[AccessD] more on early versus late binding

John

Excelent description of referencing and binding, both early and late.
No mud at all. Very, very clear.

Glen McWilliams
glen at creativehightek.com


>From: "jwcolby" <jwcolby at colbyconsulting.com>
>Reply-To: Access Developers discussion and problem 
>solving<accessd at databaseadvisors.com>
>To: "'Access Developers discussion and problem 
>solving'"<accessd at databaseadvisors.com>
>Subject: RE: [AccessD] more on early versus late binding
>Date: Mon, 12 Jul 2004 21:28:34 -0400
>
>Nope, early is not that, and late is not that.
>
>Early is dimensioning a variable as a specific object type - for example as
>an excel object or a word object or a command control etc. then referencing
>the object properties directly.
>
>Dim cbo as combo
>  debug.print cbo.Name
>
>Late is dimensioning a variable as an OBJECT data type, then referencing 
>the
>property but using the "object object".
>
>Dim cbo as object
>  debug.print cbo.name
>
>The reason it is called early and late is simply that early binding:
>
>Dim cbo as combo
>
>Causes the compiler (interpreter actually) to find and set a reference to
>the actual object (class, ocx etc) that the cbo truly is AT COMPILE TIME.
>
>Late binding causes the interpreter to "discover" what the object is by 
>what
>is stored in the variable AT RUN TIME and look up the properties and stuff
>in the actual object (library, ocx etc) at run time.
>
>Thus the early binding causes the map of dim to real thing without ever 
>even
>running the code.  Late binding simply cannot discover what to do with the
>dimensioned variable until the variable is set = to something.
>
>This is very often used to pass in different things to a function for
>example.
>
>Function MyObject(obj as object)
>   debug.print object.name
>End function
>
>Function TestObjects()
>	MyObject MyCbo
>	MyObject MyForm
>End function
>
>MyObject can be passed ANYTHING at all (objects), a spreadsheet, a word
>document, a combo box.  What happens inside of MyObject may or may not be
>legal depending on what you pass in to the function, but you can pass in 
>ANY
>OBJECT AT ALL because the compiler does not check the dimensioned type
>against the passed in type (other than to determine that it is an object).
>
>Function MyControl(txt As TextBox)
>     Debug.Print txt.Name
>End Function
>
>Function TestControls()
>Dim MyCbo As ComboBox
>Dim MyTextBox As TextBox
>Dim MyForm As Form
>     Set MyForm = New Form_Form1
>     MyControl MyForm '<<<<< ERROR AT RUN TIME
>     MyControl MyCbo
>     MyControl MyTextBox
>End Function
>
>Test control will correctly pass in controls but won't run since MyForm is
>dimensioned as a form and at RUN TIME the interpreter checks all calls to
>MyControl to see if what is being passed in is a variable of type control.
>
>With early binding, since you dimension an object specifically to its 
>object
>type, you can use intellisense because the compiler knows how to find the
>object information.  With late binding, the object type isn't determined
>until something is actually passed in so how can intellisense help you out.
>
>Hope this helps explain what early and late binding are really all about.
>
>Now... Setting the reference really has nothing to do with any of this 
>OTHER
>THAN allowing some specific object type to be found in a library, and thus
>be dimensioned to a specific object type.  IOW, If I don't reference the
>excel library, I can STILL USE EXCEL, but I have to late bind, dim as an
>object, then store an Excel object (spreadsheet, cell etc) in the variable.
>If I reference the excel library, now I can early bind and dimension a
>variable as a spreadsheet, or a cell, or whatever I want since those things
>can be found in a referenced library.
>
>So setting the reference is neither early binding nor late binding.  It
>ENABLES early binding.  If I reference the Excel lib, BUT NEVER USE ANY
>EXCEL CODE... I haven't early or late bound to Excel - I haven't used Excel
>in any way whatsoever.  However I cannot reference an excel object type 
>(dim
>a variable as a cell or spreadsheet etc) unless I reference the Excel
>library.
>
>Referencing a library does nothing more than load (before compiling) a 
>table
>of objects inside that library into a table of all possible objects for the
>compiler to use to look up dimension statement datatypes in.  If a 
>dimension
>statement datatype is not found in the table of all possible datatypes, 
>then
>a compile error is thrown on the dim statement.
>
>Clear as mud?
>
>John W. Colby
>www.ColbyConsulting.com
>