GetKeyboardState + Windows Mobile

  • Thread starter Thread starter MobileBoy36
  • Start date Start date
M

MobileBoy36

Hello Group,

To check wether the shift or control keys are pressed on a windows mobile
handheld (i will light some leds when shift or control are pressed), I would
like to run a console application (vb.net) using a function like
GetKeyboardState, unfortunatly, this one is only available on a full
windows machine OS (win32.dll).
I understand this function is not available in coredll.dll on the pocket pc
(windows mobile)
Is there any alternative? (I cannot use keyup/keydown events because another
application will have the focus)


Kind Regards,
MobileBoy36
 
I have no idea if it will work on Windows Mobile, but you could look at
GetAsyncKeyState() or use SetWindowsHookEx() to try to capture all low-level
keyboard input. However, what "shift key" are we talking about? Remember
that all of the devices with actual hardware keyboards are probably doing
things differently, as to how to achieve shift states of various sorts and
there might be *no* indication accessible to anything except the keyboard
driver to look at.

Paul T.
 
Thank You. GetAsyncKeyState works fine for the SHIFT and Control keys. To
check if the CAPS LOCK key was pressed, I needed to use GetKeyState instead,
as GetAsyncKeyState does not react when checking if CAPS LOCK is pressed.

But... GetKeyState (used for CAPS LOCK) only updates when the form I put the
code behind has focus. For the SHIFT and Control keys, the form does not
need the focus.

I also gave this a try in a console application. Again, everything OK for
SHIFT and Control, but not for CAPS LOCK :

- When CAPS LOCK is on and I execute the console application code once, it
works (the LED is burning).
- When the code is in a loop - While or a timer event - the code only reacts
on CAPS LOCK when I put a messagebox after the GetKeyState instruction.
Replacing this messagebox by a system.threading.thread.sleep does not
help... neither does putting a breakpoint over there

Does anyone have an idea about what is going on (or what am i doing wrong?)

Some (test)code snippets :

Declare Function GetAsyncKeyState Lib "coredll" Alias "GetAsyncKeyState"
(ByVal vkey As Integer) As Short
Declare Function GetKeyState Lib "coredll" Alias "GetKeyState" (ByVal vkey
As Integer) As Short

Private Sub LedOnShiftKey()
Dim CapsState As Boolean = False

CapsState = (GetKeyState(Keys.CapsLock) And 1) = 1

'System.Threading.Thread.Sleep(200) 'even waiting for a longer
period does not help
'when putting a msgbox instruction here, the CapsState value is
updated !
'as if the application needs focus for the getkeystate function to
work fine (proved this in a form application)

If (GetAsyncKeyState(Keys.ShiftKey) And 1) = 1 Xor CapsState Then
HHP.Device.UtilMethods.SetLedStatus(1,
HHP.Device.UtilMethods.LedFlags.STATE_ON)
Else
HHP.Device.UtilMethods.SetLedStatus(1,
HHP.Device.UtilMethods.LedFlags.STATE_OFF)
If (GetAsyncKeyState(Keys.ControlKey) And 1) = 1 Then
HHP.Device.UtilMethods.SetLedStatus(0,
HHP.Device.UtilMethods.LedFlags.STATE_ON)
Else
HHP.Device.UtilMethods.SetLedStatus(0,
HHP.Device.UtilMethods.LedFlags.STATE_OFF)
End If
End If

End Sub


Kind Regards



"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> schreef in bericht news:[email protected]...
 
Non-async key states are managed through the message queue so, if you have
no message queue in your application, or if you block messages from being
processed for a while, you won't get the information. So, the solution is
to have a message loop and make sure it's running, allowing GetKeyState() to
return the right value.

Paul T.

MobileBoy36 said:
Thank You. GetAsyncKeyState works fine for the SHIFT and Control keys. To
check if the CAPS LOCK key was pressed, I needed to use GetKeyState
instead, as GetAsyncKeyState does not react when checking if CAPS LOCK is
pressed.

But... GetKeyState (used for CAPS LOCK) only updates when the form I put
the code behind has focus. For the SHIFT and Control keys, the form does
not need the focus.

I also gave this a try in a console application. Again, everything OK for
SHIFT and Control, but not for CAPS LOCK :

- When CAPS LOCK is on and I execute the console application code once,
it works (the LED is burning).
- When the code is in a loop - While or a timer event - the code only
reacts on CAPS LOCK when I put a messagebox after the GetKeyState
instruction. Replacing this messagebox by a system.threading.thread.sleep
does not help... neither does putting a breakpoint over there

Does anyone have an idea about what is going on (or what am i doing
wrong?)

Some (test)code snippets :

Declare Function GetAsyncKeyState Lib "coredll" Alias "GetAsyncKeyState"
(ByVal vkey As Integer) As Short
Declare Function GetKeyState Lib "coredll" Alias "GetKeyState" (ByVal vkey
As Integer) As Short

Private Sub LedOnShiftKey()
Dim CapsState As Boolean = False

CapsState = (GetKeyState(Keys.CapsLock) And 1) = 1

'System.Threading.Thread.Sleep(200) 'even waiting for a longer
period does not help
'when putting a msgbox instruction here, the CapsState value is
updated !
'as if the application needs focus for the getkeystate function to
work fine (proved this in a form application)

If (GetAsyncKeyState(Keys.ShiftKey) And 1) = 1 Xor CapsState Then
HHP.Device.UtilMethods.SetLedStatus(1,
HHP.Device.UtilMethods.LedFlags.STATE_ON)
Else
HHP.Device.UtilMethods.SetLedStatus(1,
HHP.Device.UtilMethods.LedFlags.STATE_OFF)
If (GetAsyncKeyState(Keys.ControlKey) And 1) = 1 Then
HHP.Device.UtilMethods.SetLedStatus(0,
HHP.Device.UtilMethods.LedFlags.STATE_ON)
Else
HHP.Device.UtilMethods.SetLedStatus(0,
HHP.Device.UtilMethods.LedFlags.STATE_OFF)
End If
End If

End Sub


Kind Regards



"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> schreef in bericht news:[email protected]...
I have no idea if it will work on Windows Mobile, but you could look at
GetAsyncKeyState() or use SetWindowsHookEx() to try to capture all
low-level keyboard input. However, what "shift key" are we talking
about? Remember that all of the devices with actual hardware keyboards
are probably doing things differently, as to how to achieve shift states
of various sorts and there might be *no* indication accessible to
anything except the keyboard driver to look at.

Paul T.
Click to expand...
Click to expand...
 
Back
Top