[AccessD] more on early versus late binding

Rocky,

The issue isn't that simple.  No, after the object is bound the speed is the
same.  It's just that the object has to be looked up EVERY TIME it is bound.
If you have a function that opens a spreadsheet, with early binding this is
done ONCE at compile time.  With late binding it is done every time the
function is called.  OTOH, you no longer have to worry about lib version /
names.  

Tradeoffs.

JWC

-----Original Message-----
From: Rocky Smolin - Beach Access Software [mailto:bchacc at san.rr.com]
Sent: Tuesday, July 13, 2004 11:47 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] more on early versus late binding


John:

Re: speed, after the object is late binded, is there any difference in
execution speed?

Rocky

----- Original Message ----- 
From: "jwcolby" <jwcolby at colbyconsulting.com>
To: "'Access Developers discussion and problem solving'"
<accessd at databaseadvisors.com>
Sent: Monday, July 12, 2004 6:28 PM
Subject: RE: [AccessD] more on early versus late binding


> 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
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Susan Harkins
> Sent: Monday, July 12, 2004 2:50 PM
> To: 'Access Developers discussion and problem solving'
> Subject: RE: [AccessD] more on early versus late binding
>
>
> I kind of see the terms early and late -- in Access -- a bit differently
> than the way most documentation wants to define them. To me, early just
> means the library is referenced, hence the objects are instantiated, but
not
> being used -- late, the object is instantiated at the time it's needed --
> the reference is implicit.
>
> I see a lot of documentation that refer to setting references manually via
> the References dialog box as "early" binding, but using the References
> collection and object are never mentioned -- however...
>
> Seems to me you're setting the reference and instantiating the objects
> without using them, so, to my mind, it's early.
>
> Susan H.
>
>
> -- 
> _______________________________________________
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

-- 
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com