He, ông bạn ơi
ông thử tiêu hoá cái này thử xem:
Use Early Binding Wherever Possible
Whenever you declare a variable As Object, VBA doesn't know anything about it until runtime. Every time you call a property or method of the object, VBA has to check whether the method exists, check its parameters and confirm your code can call it. All of that takes time and should be avoided by giving all your variables specific types. If you are using As Object to be able to call the same property (for example, Name) on a number of your own classes, you should implement a custom interface in those classes instead.
***********
cái này nữa, xin bác thông cảm vì tôi kém cái món Anh văn lắm nên sợ dịch không hết nghĩa
++++++++
Early Binding vs. Late Binding
The distinction between early binding and late binding is widely misunderstood and often confused with how an object is created. The only thing that affects whether an object is early bound or late bound is how the object variable holding the reference to the object was declared. Variables declared as a specific object data type are always early bound. Variables declared with the Object or Variant data type are always late bound. Listing 3-12 shows an example of a late bound reference, and Listing 3-13 shows an example of an early bound reference.
Listing 3-12. A Late Bound Reference to an ADO Connection Object
Dim objConnection As Object
' It doesn't matter how you create the object, it's still
' late bound due to the As Object variable declaration.
Set objConnection = New ADODB.Connection
Set objConnection = CreateObject("ADODB.Connection")
Listing 3-13. An Early Bound Reference to an ADO Connection Object
Dim cnConnection As ADODB.Connection
' It doesn't matter how you create the object, it's still early
' bound due to the data type used in the variable declaration.
Set cnConnection = New ADODB.Connection
Set cnConnection = CreateObject("ADODB.Connection")
Note that to use early binding with objects that are outside the Excel object model you must set a reference to the appropriate object library using the Tools > References menu in the Visual Basic Editor. For example, to create early bound variables referencing ADO objects, you must set a reference to the Microsoft ActiveX Data Objects 2.x Library, where x is the version of ADO you intend to use.
You should use early bound object variables wherever possible. Early bound object variables provide the following advantages over late bound variables:
Improved performance When you use an object variable whose data type is known to VBA at compile time, VBA can look up the memory locations of all property and method calls you use with this object and store them with your code. At runtime, when VBA encounters one of these early bound property or method calls, it simply executes the code located at the stored location. (This is a bit of an oversimplification. What VBA actually stores is a numeric offset to the code to be executed from a known starting point in memory, which is the beginning of a structure called the object's VTable.)
When you use a late bound object variable, VBA has no way of knowing in advance what type of object the variable will contain. Therefore, it cannot optimize any property or method calls at compile time. This means that each time VBA encounters a late bound property or method call at runtime, it must query the variable to determine what kind of object it holds, look up the name of the property or method being executed to determine where in memory it is located and then execute the code located at that memory address. This process is significantly slower than an early bound call.
Strict type checking In the late bound example in Listing 3-12, if you accidentally set your object variable to reference an ADO Command object instead of a Connection object, VBA would not complain. You would only discover you had a problem downstream in your code when you tried to use a method or property not supported by the Command object. With early binding, VBA will immediately detect that you are trying to assign the wrong type of object reference to your object variable and notify you with a "Type mismatch" error. Incorrect property and method calls can be detected even earlier, before the code is ever run. VBA will attempt to look up the name of the property or method being called from within the appropriate object library at compile time and throw an error if the name cannot be located.
IntelliSense availability Early bound object variables make for much easier programming as well. Because VBA knows exactly what type of object a variable represents, it can parse the appropriate object library and provide a drop-down list of all available properties and methods for the object as soon as you type a dot operator after the variable's name.
As you might expect, in some cases you need to use late binding rather than early binding. The two most common reasons for using late binding rather than early binding are as follows:
When a newer version of an application's object library has broken compatibility with an earlier version.
This is an all too common situation. If you set a reference to the later version of the application's object library in your application and then attempt to run it on a computer that has the earlier version, you will get an immediate compile time error "Can't find project or library," and the reference on the target machine will be prefixed with MISSING. The most insidious thing about this error is that the line of code flagged as being the source of the error will often have nothing to do with the object library actually causing the problem.
If you need to use objects from an application that exhibits this problem and you want to support users with any version of the application, you need to use late binding for all variables referencing objects from the application. If you are creating new objects, you also need to use the CreateObject function with the version-independent ProgID of the object you want to create, rather than the = New ObjectName syntax.
When you want to use an application that you cannot be sure will exist on the user's computer and that you cannot install yourself.
In this case, you need to use late binding to avoid the compile time error that would immediately result from attempting to run an application that referenced an object library that did not exist on the user's computer. Your application can then check for the existence of the object library in question and exit gracefully if that library is not installed on the user's computer.
TIP
Even if you will eventually use late binding in your code, early binding offers such a great increase in productivity while coding that you should write and test the application using early binding. Convert your code to late binding only for the final round of testing and distribution.
++++++++++++
trích trong cuốn:
Professional Excel Development: The Definitive Guide to Developing Applications Using Microsoft® Excel and VBA®
By Stephen Bullen, Rob Bovey, John Green
Mà hình như cuốn này có trong thư viện Gmail đó