When programming in WinAPI a Keyboard filter can be installed that traps specific keys ... there is a way to stop the windows message handler from passing the key any further ... in VBA we can do a key preview at the form level but I can't figure out how to have the process stop at this point ie terminate the message. Is this possible?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
KeyPress filter 1
- Thread starter bkdobs
- Start date
-
1
- #2
- Thread starter
- #3
Roy
Sorry ... I am looking for a solution in ACCESS for the Keypress/up/down event ... should one expect that the Visual Basic group would have an answer for this? I realize that VBA is a subset of Visual Basic but is it exactly the same in terms of how it deals with message handling? I will go take a look there to see if this has been answered before.
sub form_keypress(KeyAscii)
debug.print "Form" & KeyAscii
If keyAscii = somekey then
<do something to stop passing message on to control>
end if
end sub
sub control_keypress(KeyAscii)
debug.print "Control" & KeyAscii
end sub
Currently both events always print KeyAscii even if I change the value of KeyAscii in the Form event
Sorry ... I am looking for a solution in ACCESS for the Keypress/up/down event ... should one expect that the Visual Basic group would have an answer for this? I realize that VBA is a subset of Visual Basic but is it exactly the same in terms of how it deals with message handling? I will go take a look there to see if this has been answered before.
sub form_keypress(KeyAscii)
debug.print "Form" & KeyAscii
If keyAscii = somekey then
<do something to stop passing message on to control>
end if
end sub
sub control_keypress(KeyAscii)
debug.print "Control" & KeyAscii
end sub
Currently both events always print KeyAscii even if I change the value of KeyAscii in the Form event
Oh - I completely misunderstood, I thought you where after some API-stuff, not just
[tt]keyascii = 0[/tt]![[blush]](/data/assets/smilies/blush.gif "[blush] [blush]")
though, I think this is roughly the same as in VB too.
(I think also someone would surely like to discuss which is a subset of which, but that's probably another discussion;-))
Roy-Vidar
[tt]keyascii = 0[/tt]
though, I think this is roughly the same as in VB too.
(I think also someone would surely like to discuss which is a subset of which, but that's probably another discussion;-))
Roy-Vidar
- Thread starter
- #5
- Thread starter
- #7
Thanx Roy
Sorry! LIGHTS ON NOBODY HOME .... after writing the blurb below it finally clicked!!! ... In order to trap the characters at the FORM level WE/I NEED TO USE the Form_KeyDown Event ... The KeyPress event interprets the Key after KeyDown which is allowing the KeyDown message to get through to the Control. So setting KeyCode to 0 does terminate the message.
A Key entry produces 3 window messages the Keydown, then KeyPress, then KeyUP
************** SNIP SNIP SNIP ******************
The windows message handler passes Key events to the parent Application in focus and on down to the control in focus ... when programming in the API (a bit fuzzy now over 10 years ago) I recall there being a return value that can be passed back to the handler to say this event has been handled so don't pass it on to any other processes.
In this case, all we are doing is changing the value of the Key which obviously is not being interpreted by the handler so it is still being passed along to the child controls ... is this a problem? ... depends on the character we are trying to trap ... in the example in my previous post the control Keypress is getting the new Keyascii value which proves to me that the message handler is not recognizing that this key has been dealt with.
When I attempt to trap a 0x0d <CR> it appears that a list control is still interpreting the <cr> before the Form event is triggered ... ie the entry changes to inverse even though I am changing the Keypress value to 0 at the FORM Keypress Event
yes I have the KeyPreview set that is why the form_keypress event is firing ... I can also certainly add a test for 0 in the control keypress/up/down event so that it simulates the desired effect. I am however concered that ACCESS will interpret the key for other functionality if it is still being passed along. Without knowing the actual Tree/Path of ACCESS's Key Event handling its hard to know if this is a good way to handle trapping characters.
I have used this method in C++/API to intercept Ctrl Chars, hot keys, function keys for stuff like overriding Windows default form Navigation using arrow keys (bypassing tab sequences/order) which has worked great in the past.
Sorry! LIGHTS ON NOBODY HOME .... after writing the blurb below it finally clicked!!! ... In order to trap the characters at the FORM level WE/I NEED TO USE the Form_KeyDown Event ... The KeyPress event interprets the Key after KeyDown which is allowing the KeyDown message to get through to the Control. So setting KeyCode to 0 does terminate the message.
A Key entry produces 3 window messages the Keydown, then KeyPress, then KeyUP
************** SNIP SNIP SNIP ******************
The windows message handler passes Key events to the parent Application in focus and on down to the control in focus ... when programming in the API (a bit fuzzy now over 10 years ago) I recall there being a return value that can be passed back to the handler to say this event has been handled so don't pass it on to any other processes.
In this case, all we are doing is changing the value of the Key which obviously is not being interpreted by the handler so it is still being passed along to the child controls ... is this a problem? ... depends on the character we are trying to trap ... in the example in my previous post the control Keypress is getting the new Keyascii value which proves to me that the message handler is not recognizing that this key has been dealt with.
When I attempt to trap a 0x0d <CR> it appears that a list control is still interpreting the <cr> before the Form event is triggered ... ie the entry changes to inverse even though I am changing the Keypress value to 0 at the FORM Keypress Event
yes I have the KeyPreview set that is why the form_keypress event is firing ... I can also certainly add a test for 0 in the control keypress/up/down event so that it simulates the desired effect. I am however concered that ACCESS will interpret the key for other functionality if it is still being passed along. Without knowing the actual Tree/Path of ACCESS's Key Event handling its hard to know if this is a good way to handle trapping characters.
I have used this method in C++/API to intercept Ctrl Chars, hot keys, function keys for stuff like overriding Windows default form Navigation using arrow keys (bypassing tab sequences/order) which has worked great in the past.
- Status
Similar threads
- Locked
- Question