Rocky Smolin - Beach Access Software
bchacc at san.rr.com
Wed Jul 14 10:12:10 CDT 2004
John: Another clarification, please: "...every time the function is called." Does this mean every time the "Set ojbX = " is executed or every time I reference the object while I've got the object open. I might set an object to a spread sheet or word doc once but refer to it thousands of times before I close it. And maybe I'm writing simple apps, but I've pretty much given up trying to optimize my code up front for speed and gone for clarity and maintainability instead. Because it doesn't seem to make any difference. I rarely have a client say something is running too slow. Rocky ----- Original Message ----- From: "Colby, John" <JColby at dispec.com> To: "'Access Developers discussion and problem solving'" <accessd at databaseadvisors.com> Sent: Wednesday, July 14, 2004 7:26 AM Subject: RE: [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 > -- > _______________________________________________ > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com >