Page 1 of 1
Why Keys blocked?
Posted: Tue Sep 16, 2003 11:29 pm
by LCD
ExamineKeyboard()
If KeyboardPushed(#PB_Key_A):....:EndIf
after return from the subroutine which uses this kind of control, the keyboard did not work anymore in the ExplorerTreeGadged, String Gadget and probably other gadgets too. I can then use mouse only to select files/text. ExamineKeyboard() itself is harmless, but KeyboardPushed()/KeyboardReleased() blocks the complete keyboard input to the gadgets. Is there a way to unblock keyboard, so the keys will work again with windows gadgets, or is it a bug?
Posted: Wed Sep 17, 2003 12:01 am
by Karbon
I'm not sure about using the keyboard lib in an application... This is one way to check for enter being pressed :
Code: Select all
Select MyEventID
Case #WM_KEYDOWN
If EventwParam() = 13
Select EventGadgetID()
Case #String_Gadget_Here
Debug "Return key pressed in string gadget"
EndSelect
EndIf
EndSelect
.. It should work for any key.. Most would suggest using AddKeyboardShortcut() though as it's a bit more reliable...
Posted: Wed Sep 17, 2003 12:22 am
by Kale
Code: Select all
InitKeyboard()
ExamineKeyboard()
If KeyboardPushed(#PB_Key_A):....:EndIf
etc...
These commands use DirectX v7.0+ and should not really be used in apps (unless you need to use DirectX for something else e.g. a windowed screen.).
You could maybe use a CallBack or shortcuts as Karbon said.
Posted: Wed Sep 17, 2003 12:52 am
by LCD
I use the DX7 keyboard control to control the scrolling in zoom mode of my application, and it is working in windowed screen mode.
Shortcuts for scrolling is a bit unusual, but I will test the other method tomorrow. Any idea why it blocks gadgets?
Posted: Wed Sep 17, 2003 9:17 am
by Skipsy
Hello,
Try : GetAsyncKeyState_(ascii_key) instead of KeyboardPushed()
Enjoy.
Posted: Wed Sep 17, 2003 5:12 pm
by LCD
GetAsyncKeyState_(ascii_key) returns zero (ascii_key=97 for "a") if key pressed. It works well with (13), so I hope, it will work with cursors too, but what are the ASCII for cursor keys?
Posted: Wed Sep 17, 2003 5:37 pm
by Pupil
Check win32 API, for virtual key codes:
Code: Select all
#VK_LEFT = 25 ;LEFT ARROW key
#VK_UP =26 ;UP ARROW key
#VK_RIGHT = 27 ;RIGHT ARROW key
VK_DOWN = 28 ;DOWN ARROW key
You probably don't have to define the constants though as they're probably already available in PB.
Posted: Wed Sep 17, 2003 6:34 pm
by LCD
Thx, Pupil, it works fine, except the CHR codes are wrong, for example #VK_DOWN is the constant for 40 (probably because I'm damned to use a german keyboard?), but it works with these constants. Excellent. I guess, I can now throw out all DX keyboard command. Still no idea why it kills API input? (Don´t says because these are Micro$oft products)
Posted: Wed Sep 17, 2003 6:49 pm
by Karbon
This is a total guess but if you use the DX keyboard controls then the app is handing over all control of the keyboard to DX?
Posted: Wed Sep 17, 2003 7:26 pm
by Pupil
LCD wrote:Thx, Pupil, it works fine, except the CHR codes are wrong, for example #VK_DOWN is the constant for 40 (probably because I'm damned to use a german keyboard?)...
Hmm, that's because they are hex values
only i forgot to add the '$' to make them so when i was doing the copy n' paste routine
Posted: Wed Sep 17, 2003 7:54 pm
by LCD
@Pupil: Eh, Hex... I see. Should figure this out next time. I do not care about how you write hex (0xFF or $FF for 255).
@Karbon: But after the DX handling is over, should it not hand over the keyboard controls to the app? If it sounds like a bug, it is probably a bug. I´m just curious what Fred says about this.
Posted: Thu Sep 18, 2003 2:53 am
by PB
> the CHR codes are wrong [for letters]
Use #VK_A through #VK_Z for letters.
Posted: Thu Sep 18, 2003 9:00 am
by LCD
PB wrote:> the CHR codes are wrong [for letters]
Use #VK_A through #VK_Z for letters.
Okay, thanks!!!