I was thrilled to discover Stephen Leban's method of programmatically
scrolling a list box --
http://www.lebans.com/List_Combo.htm#ScrollListbox

My problem is, I want to scroll the list box as the user is typing
into a text box. I'm using the text box's Change() event. The
scrolling works, but it forces the list box to get the Focus. Of
course this means that the user is interrupted after every character.
I can give the focus back to the text box but the whole field is then
selected and the cursor is not at the end of the field.

I suspect there is some way to declare an Alias to a Windows API that
can restore the cursor to a given location in the text field?

Composer wrote:


Try saving the text box's SelStart and SelLength properties
before moving the focus and restoring them after the focus
is returned to the text box.

--
Marsh

That is very helpful, and simpler than I expected. Thanks!

I now arrive at a new problem. When the user's input includes a
space, the trailing space gets lost. I've tried saving the text box
contents and restoring them (temporarily disabling the text
box's .OnChange spec), but that doesn't work. Thanks for any ideas.

I've gotten around this new problem by simply not doing any scrolling
when the last character is a blank. For my users this is acceptable.

An even simpler approach to what you are doing is to use a Combo Box, with
its AutoExpand property set to Yes (which is the default). Combo is a
combination of a List Box and a Text Box shown together, and the List Box
scrolls as you type in the Text Box. The only limitation that I can think is
that the Control combines both Text and List Boxes and you can't separate
them... but it avoids both the problem you described, and also the need for
VBA code, API calls, etc. to "make it happen".

IMNSHO, one of the great advantages of Access is the number of useful
features and functions that it provides, automatically, "right out of the
box" without having to jump through hoops to make it work the way it ought
to, as do some other development tools.

Larry Linson
Microsoft Office Access MVP

"Composer" <composer (AT) uwclub (DOT) net> wrote

Thanks, Larry.

That is indeed a more elegant solution. In my case it might not be
ideal.

The list box is there so the user can pick an existing value, which
the user will do 99% of the time. The text box is there if the value
isn't in the list, and the user needs to add it to the list. When the
user is typing a new value, I want to scroll the list just to make
doubly sure the user has looked to see whether the value isn't already
in the list.

The list needs to stay separate from the text box, because the user
can do other things with the list entries, like click one and then
edit it. I don't see a user-friendly way to do this with a combo
box; either the user selects an item from the combo (meaning I should
do X with the selection) or they add a new item (which I handle via
NotInList). I need to do X, Y, or Z with the list box selection, so
I'd better stick with the list box.

But many thanks for the idea, which I'll probably use in the future.

I'm afraid I don't understand why you can't, or don't want to, use the same
logic to determine what to do with a selection from a Combo Box that you do
to determine what to do with a selection from a List Box. There's nothing
that restricts you to "doing only one thing" with a Combo selection any more
than there is anything that would restrict you to "doing only one thing"
with a List selection.

(With a List Box, you can specify Multi-Select, so that you can highlight
and have several of the included values selected, but that really adds to
the code you have to write to process them.)

Larry Linson
Microsoft Office Access MVP


"Composer" <composer (AT) uwclub (DOT) net> wrote