[AccessD] more on early versus late binding

:)

John W. Colby 
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Glen McWilliams
Sent: Tuesday, July 13, 2004 9:15 PM
To: accessd at databaseadvisors.com
Subject: RE: [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
>