Setting up a form to use the mouse as little as possible

[AdamOnAccess]

I'm trying to set up a form so the user doesn't have to use a mouse at all if they do not want to. When they want to move to a different control, I set up captions with an "&" in the names to serve as hot keys.

Now I'm trying to set up a list box. I used ListBoxName.Set focus and ListBoxName.Sel ect(0)=True to get me to the top of the list. I would like to allow the user to simply use the arrow keys (or any appropriate keys) to move down the list and then hit the space bar, or the enter key to make their choice.

Problem is, when I try the down arrow key, the listbox takes that as a selection. Does anyone know how I can set up this list box to work without a mouse?

Thanks,
Adam

[NeoPa]

I expect the Dropdown method of the control is what you're after here Adam.

[AdamOnAccess]

Hi NeoPa,

I looked up some info on the dropdown method but only found references to combo boxes. From what I've read, the dropdown method forces a combo box to show it's list. I'm using a list box control so the data is already exposed - no drop down is necessary. I checked the Object Browser under listboxes and I didn't see the DropDown method listed for list boxes; only combo boxes. Just to be sure, I tried:

Private Sub lstbPhrases_GotFocus()
    Me!lstbPhrases.Dropdown
End Sub

... and got "Object doesn't support this property or method"

Did you think I was using a combo box, or is there a way to apply this method to a list box that I'm missing?

Thanks,
Adam

[NeoPa]

Sorry Adam. My bad.

I knew it was a ListBox but I couldn't find one to check with in my open database so I did it on a ComboBox. By that time I'd completely forgotten that I wasn't dealing with one of those, but a ListBox which doesn't drop down anyway. Doh!!

PS. Please notice the edit comment. All code must be posted in the [noparse][CODE][noparse] tags. This is not optional I'm afraid.

[OldBirdman]

Dropdown method is for ComboBoxes, and doesn't work for ListBoxes. What is needed here is to capture the key in the KeyDown event and respond accordingly.

Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
    Select Case KeyCode
        Case vbKeyPageUp '0x21
            Call MoveRecord(-26)
        Case vbKeyPageDown '0x22
            Call MoveRecord(26)
        Case vbKeyEnd '0x23
            Call MoveRecord(iixSelectCount)
        Case vbKeyHome '0x24
            Call MoveRecord(-iixSelectCount)
        Case vbKeyUp '0x26
            Call MoveRecord(-1)
        Case vbKeyDown '0x28
            Call MoveRecord(1)
    End Select
End Sub 'Form_KeyDown

The subroutine 'MoveRecord' moves the selected line the number of rows passed to it, but checks for movement beyond the current size. The vbKeyLeft & ...Right are not used, but could be used for an Up 10 or Down 10. In my case, the listbox is 26 rows, and so the Down 26 might not do an actual page, but only move the cursor to the bottom. Using the mouse in the vertical scroll bar effectively does a Down 27. This difference means that the keyboard shows the row at the bottom moved to the top, whereas the mouse shows a completely new list.
Access does not have a TopRow property for listboxes (or comboboxes), so the code cannot know the relative position of the row selected within the control displayed.

[AdamOnAccess]

NeoPa, OldBirdman,

Thank you both for the help.

OldBirdman, I used your approuch but not with all the bells and whistles. Turns out that if you don't have any click or afterupdate events, the list box handles the up and down arrow keys. It doesn't take Home and End keys. I simply trapped the space-bar keydown event for the list box and it works fine.

Thanks Again,
Adam

[NeoPa]

No worries Adam.

What I often do, to avoid complication and operator confusion, is to require the Shift key to be used for accessing anything special. This has the effect that the operator can still use the normal keys just as they would be used to doing, but they use your extra shortcuts if they have a mind to. It may not be appropriate if you want the operator to be completely unaware that this is even going on of course, but the idea's there anyway. Use it if it fits.

[OldBirdman]

Adam,
I stripped out all of the whistles and most of the bells before posting. I want it both ways, mouse OR keyboard. Once on the keyboard (hands at standard typing location of ASDF/JKL;) I want to stay there as long as possible.
However, if I must change to the mouse (right hand w/mouse, left used for cntl-C, cntl-V, Tab, shift-Tab, cntl-A, etc.) then I want to stay there as long as possible. Continually switching is something I seriously want to avoid.
Of course, I don't want to do anything that is unexpected for Windows users.

[AdamOnAccess]

OldBirdman,

I couldn't agree more: Continually switching slows data entry to a crawl and should be avoided. I'm going so far as to creating forms specifically designed around tasks that involve one-hand keyboard and mouse position, and forms that should be all keyboard. I find this really speeds up entry.

Thanks Again,
Adam