Image Map of Navigational Panel to Home / Contents / Search Late Versus Early Binding

by Peter Wone - GUI Computing

Image of line

In Access Basic and VBA you can bind an object reference at compile-time or at run-time. An expression like Set F = Forms![MyForm] is completely resolved at compile-time, whereas the code in figure one can only be resolved at run-time.

  Dim Astring As String
  Dim F As Form
  Let Astring = "MyForm"
  Set F = Forms(Astring)

The expression in figure one is resolved depending on the value of the string parameter. The string value identifying a form is the value of its Name property. You can also late bind using an integer parameter, but this is useful only for walking the whole forms collection. Form numbers are far too difficult to interpret during debugging.

All this applies to objects at large, not just forms. The consequence of late binding is that abstracted references are possible: parametric library subroutines can be constructed.

So what are the pros and cons of late and early binding? Well, early binding is much faster at run-time, but manual changes to code are necessary whenever anything’s Name property is changed. Abstracting object references makes code more maintainable and generic. It carries run-time performance costs, but these are progressively ameliorated by platform technology improvements(1) whereas maintenance penalties imposed by explicit object references in code carry fixed overheads(2).

You may be wondering how Set F = Forms("MyForm") can be less trouble to maintain than Set F = Forms![MyForm]. One answer is that (Cobol lives!) you can keep a module full of declarations like Const F_SPLASHBOX = "Splash screen" and refer to the constant like so: Set F = Forms(F_SPLASHBOX). This is, of course, the least of a nigh endless list of possible, but it makes the point nicely.

For those wondering how late binding actually works, the program builds a table of named object instance pointers at run-time. When you make a late bound reference to an object, your program searches its list for a matching name. If it finds one, the reference is resolved to a pointer(3), otherwise it searches its list of defined (as opposed to instantiated) objects. If it finds a match there, it instantiates the object and resolves the expression to a pointer, otherwise an error is generated indicating the non-existence of the nominated object.

Access Basic both try to protect us from ourselves by disallowing use of the Set command on object variables passed to subroutines as formal parameters. The dodge for this is to pass not an object variable but a HAD (handle to array descriptor) thus bollixing type checking. Check out Jim Karabatsos’ section in last issue for details.

Unfortunately VB3 does not support object collection references by name. One might hope that this deficiency will be corrected in VB94. I mean, I’ve heard... but who knows?


1.Faster boxes.
2.Nobody’s building faster programmers.
3.Yes, a pointer. What did you think object variables contained, fairy-dust?

Written by: Peter Wone
June 94

Image of arrow linked to previous page Image of arrow linked to next page
Image of line
[HOME] [TABLE OF CONTENTS] [SEARCH]