P
Peter Hallett
When a parameter is selected from a combo box, it is often subsequently
employed to determine associated values. A selected surname, for example,
may be used to find an associated ID and/or invoice number.
As a simpler, and presumably more efficient, alternative to using a series
of DLookups, the combo box can be bound not just to the name field of a table
or query, but to the other required fields as well. Having selected the
surname, the associated values can then be read directly as Name.Column(1),
Name.Column(2), etc., where the surname itself is in the default column,
Name.Column(0), or simply Name.
This works quite well if the columns are made wider than the width of the
combo box, thus effectively hiding the additional fields. One snag, however,
is that a horizontal scroll bar is automatically added to the bottom of the
drop-down list which, in such applications, is generally superfluous and can
be distracting. Unlike in form design, there does not appear to be an
obvious mechanism for hiding this feature. Can it be done?
employed to determine associated values. A selected surname, for example,
may be used to find an associated ID and/or invoice number.
As a simpler, and presumably more efficient, alternative to using a series
of DLookups, the combo box can be bound not just to the name field of a table
or query, but to the other required fields as well. Having selected the
surname, the associated values can then be read directly as Name.Column(1),
Name.Column(2), etc., where the surname itself is in the default column,
Name.Column(0), or simply Name.
This works quite well if the columns are made wider than the width of the
combo box, thus effectively hiding the additional fields. One snag, however,
is that a horizontal scroll bar is automatically added to the bottom of the
drop-down list which, in such applications, is generally superfluous and can
be distracting. Unlike in form design, there does not appear to be an
obvious mechanism for hiding this feature. Can it be done?