List Box Click Event Anomaly.

  • Thread starter Thread starter Peter Hibbs
  • Start date Start date
P

Peter Hibbs

Access 2003.

I have a form with a List Box control, the Row Source is linked to a
query to show a list of client addreses. The List Box control is third
in the Tab order so the user will press the TAB key and move the
cursor to the List Box, use the Up and Down arrow keys on the keyboard
to select a record in the list and then click the selected record to
display some information about the client.

The problem is that as soon as they press an arrow key, the List Box
Click event is triggered and they get the first client in the list
instead of the one they want. This seems to be a feature of Access
List Box controls as it also does it on other forms and other
databases.

Is there any easy way to prevent the Click event triggering when an
arrow key is pressed on a keyboard but still trigger when they click
on the List box with the mouse?

Peter Hibbs.
 
Bonnie,

The only event used on the List boxes is the On Click event. Are you
suggesting, then, that this is not the normal behaviour for a List box
control?

Peter.
 
Bonnie,

I had never noticed this effect either. I can use the Double Click
event and this does work but the users don't like using double
clicking much but....

Peter Hibbs.

You're right Peter, never noticed it before. You can use Dbl Click however.

Peter said:
Bonnie,

The only event used on the List boxes is the On Click event. Are you
suggesting, then, that this is not the normal behaviour for a List box
control?

Peter.
Peter make sure you don't have anything in your OnChange event for the list
box.
Click to expand...
[quoted text clipped - 22 lines]
Peter Hibbs.
Click to expand...
Click to expand...
Click to expand...
 
Linq,

I am not sure how that is going to help. It seems that the arrow keys
ALSO trigger the AfterUpdate event as well as the Click event.

Peter.
 
Bonnie,

Will do (by telephone I think).

Peter.

Tell the users - sometimes life is tough!

Bon
http://www.dataplus-svc.com

Peter said:
Bonnie,

I had never noticed this effect either. I can use the Double Click
event and this does work but the users don't like using double
clicking much but....

Peter Hibbs.
You're right Peter, never noticed it before. You can use Dbl Click however.
Click to expand...
[quoted text clipped - 11 lines]
Peter Hibbs.
Click to expand...
Click to expand...
Click to expand...
 
Peter Hibbs said:
Access 2003.

I have a form with a List Box control, the Row Source is linked to a
query to show a list of client addreses. The List Box control is third
in the Tab order so the user will press the TAB key and move the
cursor to the List Box, use the Up and Down arrow keys on the keyboard
to select a record in the list and then click the selected record to
display some information about the client.

The problem is that as soon as they press an arrow key, the List Box
Click event is triggered and they get the first client in the list
instead of the one they want. This seems to be a feature of Access
List Box controls as it also does it on other forms and other
databases.

Is there any easy way to prevent the Click event triggering when an
arrow key is pressed on a keyboard but still trigger when they click
on the List box with the mouse?
Click to expand...


You might be able to set a module-level flag variable in the MouseDown
event, and then reset it in the Click event. Your code in the Click event
would check to see if flag was set when the event procedure was triggered,
thus allowing you to determine if the Click event was really raised by mouse
action.
 
Dirk,

Thanks for the idea, your idea did not work but I have found a
solution using a similar method but the other way round. I have used
the Key Down and Key Up events of the List box to ignore the OnClick
event like so :-
------------------------------------------------------
Option Compare Database
Option Explicit

Dim vCheck As Boolean
------------------------------------------------------

Private Sub lstClients_Click()

If vCheck = True Then Exit Sub
' other click event code........

End Sub
------------------------------------------------------

Private Sub lstClients_KeyDown(KeyCode As Integer, Shift As Integer)
vCheck = True
End Sub
------------------------------------------------------
Private Sub lstClients_KeyUp(KeyCode As Integer, Shift As Integer)
vCheck = False
End Sub
------------------------------------------------------

It seems to work OK. I don't know if there is a simpler method but
this seems to work.

Thanks to everyone for their invaluable input.

Peter Hibbs.
 
Peter Hibbs said:
Thanks for the idea, your idea did not work
Click to expand...

What was wrong, if you don't mind my asking? I can't see why it wouldn't
work, if implemented correctly.
but I have found a
solution using a similar method but the other way round.
Click to expand...

Regardless, I'm glad you found a solution.
 
Dirk,

It could be that "implemented correctly" is the relevant part but I
used this logic with the code below. When the mouse is down the vCheck
flag is Set and when the mouse is released the vCheck flag is reset.

When the list box gets the focus (with the TAB key) and the arrow keys
are then pressed, the vCheck flag will be False and so the Click event
will be triggered but is be ignored, i.e. the routine will exit
immediately. And this works OK, the arrow keys move the cursor up and
down the list of entries.

My idea was that when the user actually clicked on a list box entry,
the vCheck flag would be set True and so the Click event code would
then execute. But it doesn't happen, it seems the flag is still False
when the Click event triggers and the code just exits the routine.


Private Sub lstClients_Click()

If vCheck = False Then Exit Sub
'...code here....

End Sub

Private Sub lstClients_MouseDown(Button As Integer, Shift As Integer,
X As Single, Y As Single)
vCheck = True
End Sub

Private Sub lstClients_MouseUp(Button As Integer, Shift As Integer, X
As Single, Y As Single)
vCheck = False
End Sub

If you have some alternative code I would be interested to see it
although, as I said, my code does work.

Peter Hibbs.
 
Peter Hibbs said:
Dirk,

It could be that "implemented correctly" is the relevant part but I
used this logic with the code below. When the mouse is down the vCheck
flag is Set and when the mouse is released the vCheck flag is reset.

When the list box gets the focus (with the TAB key) and the arrow keys
are then pressed, the vCheck flag will be False and so the Click event
will be triggered but is be ignored, i.e. the routine will exit
immediately. And this works OK, the arrow keys move the cursor up and
down the list of entries.

My idea was that when the user actually clicked on a list box entry,
the vCheck flag would be set True and so the Click event code would
then execute. But it doesn't happen, it seems the flag is still False
when the Click event triggers and the code just exits the routine.


Private Sub lstClients_Click()

If vCheck = False Then Exit Sub
'...code here....

End Sub

Private Sub lstClients_MouseDown(Button As Integer, Shift As Integer,
X As Single, Y As Single)
vCheck = True
End Sub

Private Sub lstClients_MouseUp(Button As Integer, Shift As Integer, X
As Single, Y As Single)
vCheck = False
End Sub

If you have some alternative code I would be interested to see it
although, as I said, my code does work.
Click to expand...


The sequence of events for a mouse click on a control is:

MouseDown -> MouseUp -> Click

So your code, which resets vCheck in the MouseUp event, will result in
vCheck always being False in the Click event. You should reset vCheck in
the Click event instead:

'------ start of revised code ------
' Declared at module level
Dim vCheck As Boolean

Private Sub lstClients_Click()

If vCheck = False Then Exit Sub

vCheck = False

'...code here....

End Sub

Private Sub lstClients_MouseDown(Button As Integer, Shift As Integer,
X As Single, Y As Single)
vCheck = True
End Sub

'*** NO lstClients_MouseUp EVENT PROCEDURE ***
'------ end of revised code ------
 
Dirk,

Yes, that works fine. I will use your solution, I think, as it is
slightly simpler than mine.

Thanks again.

Peter Hibbs.
 
Back
Top