How do you do a comparison to see if the key that was pressed for a keydown event was one of the left, right, up, down, arrow direction keys on the keyboard?
arrow keys return CHRB(28), 29, 30 and 31
all you had to do was put code in the key down event to expose the ASC value and you can tell what ANY key returns
NOT TO BE CONFUSED with “keycode”
Ed:
I may seems strange to you, but you will find an explanation there:
http://documentation.xojo.com/index.php/Canvas
the example in the Notes part.
I had to do something similar recently in a canvas KeyDown event:
[code] //CURSOR SCROLL/PAN-------------------
Select Case True
Case Keyboard.AsyncKeyDown(&h7B) //Scroll LeftArrow
cursorPosition = cursorPosition - 1
Case Keyboard.AsyncKeyDown(&h7C) //Scroll RightArrow
cursorPosition = cursorPosition + 1
End Select
// &h7B left, &h7C right, &h7E up, &h7D down, &h31 spacebar
// AsyncControlKey CTRL, AsyncAltKey ALT, AsyncShiftKey SHIFT[/code]
This was for moving an object within the canvas and works fine in my situation.
@ Dave & Emile: I did look at that method and read about keycode but it became confusing.
If you found keycodes confusing then why did you use them
in key down
SELECT CASE key
case chrB(28)
' move
case chrB(29)
' move
case chrB(30)
' move
case chrB(31)
' move
end selectI don’t recall off the top of my head which direction goes with which key… and Keycodes (my opinion) should be avoided like the plague… as they are different for different keyboards.
Oh Ok, thanks Dave. Well, there you go, that’s how confused I still am - I thought I was doing it the correct way.
What about modifiers like Shift, Ctrl etc?.
Also, when you say keycodes can be “different for different keyboards” are you referring to cross-platform, or keyboards in general?
from the lang ref
AZERTY
QUERTY
The KeyCode for the A/Q (right of the Tab key) character is the same (of course). So, if you rely on key code and your application is used worldwide, how do you know what the character is: A or Q ?
KeyCode is the reference of the key (in the hardware; the address of each keyboard key, regardless of what is printed in the key cap),
Character is the Keyboard layout (what is printed in the key caps, if you use the corresponding language setting).
Now, in games for example, KeyCode can be of good use, but you have to provide an artwork that explains the use of that keyboard.
Keyboard layout: think at a dictionary that have a key code / character paint for each key cap. Since you can change the keyboard layout in the system (OS), you will usually deals with the returned character. One Key COde may return a different character depending on the selected Keyboard layout.
Relevant entries:
http://documentation.xojo.com/index.php/Keyboard.Keyname
http://documentation.xojo.com/index.php/Keyboard
I hope this is clear, now.
[quote=305471:@Steve Kelepouris]Oh Ok, thanks Dave. Well, there you go, that’s how confused I still am - I thought I was doing it the correct way.
What about modifiers like Shift, Ctrl etc?.
Also, when you say keycodes can be “different for different keyboards” are you referring to cross-platform, or keyboards in general?[/quote]
Arrow keys keycodes don’t change. Nor do Ctrl, Alt-Option and Cmd. Although Cmd becomes Window key on Windows.
But under Windows, keycodes change according to the keyboard layout. So for instance in a French keyboard, a and q are swapped, as well as w and z.
In Mac, keycodes are not localized. So when you think the user typed “q”, he will have typed “a” instead. That is quite confusing.
If you can, use key in keydown, and the keyboard class for modifiers only. I do use the keyboard class, but only when I cannot rely on the keydown event. For instance to pop a window through a key combination, as I do for Char Menu.
[quote]Arrow keys keycodes don’t change. Nor do Ctrl, Alt-Option and Cmd. Although Cmd becomes Window key on Windows.
[/quote]
Well that’s all I needed to know, thanks for the clarity Michel. If the user types “q” and it becomes “a” instead, well that is indeed confusing, but workable if you know how to account for it.
It’s not an issue for me and probably not an issue for the OP considering the question was regarding arrow keys.
It becomes quite complex when the app is in the wild. There are dozens upon dozens of different keyboard layouts, and short of having a full database of layout, accounting for it is a daunting task.
That is precisely why you want to let the system take care of it transparently.
In the Keydown event, use Keyboard.ControlKey, etc. Do not use the Async versions in this event.
Hi Tim, what’s the reason for this? I looked through my main project and I had used the Async version in a couple of KeyDown events, but also saw it done in a couple of 3rd party controls that I own source.
Keyboard.ControlKey means whatever state the control key was in when this was checked, so if you have a long script and the state of the control key changes, this value doesn’t
Keyboard.AsyncControlKey means the value will change based on the state of the key, in real time… (so someone tapping on the control key would keep switching it between TRUE and FALSE)
Thanks for the explanation. I’ll have to think about what this does and figure out which one is better.
@ Tim. Thanks, I did try that suggestion and used Keyboard.ControlKey (and the others: ShiftKey, AltKey etc.) and determined no operational difference with my software.
The reason I’ve become involved in this thread is that I had similar requirements to the OP. I did some research and found varying solutions and none of them definitive. I chose one method, and it works fine for me.
Seems like there are different ways to go about capturing keyboard events depending on the circumstance, usage and requirements. With my limited experience, it’s more complicated than I ever imagined. However, it would be good to understand for future reference.
It would be great if someone was able to create a video tutorial with clear worked through examples showing how, when and where these various methods to capture keyboard events are used.
An example where the use of keyboard.asynchkeydown event works well is with a canvas or OpenGLSurface where a for-loop is used instead of a timer to increase the refresh rate for drawing on these controls.
Drawing graphics with a timer works well on Mac with keydown events, and graphics on Windows works better without timers and the use of keyboard ascych seems to work well.
Do you know you can add keyboard shortcuts (and display them) on PushButtons ?
Keyboard.ControlKey (and the others) is the state of the key at the time the event was queued for processing. The Async version is the state of the key at the time the code in the event is running. A fast typist can get the async version out of sync with the event processing. I have done this myself.
In general, use ControlKey in the KeyDown event, and AsyncControlKey in other events. You might not notice the difference in testing, but your users might well experience it in the field.
Ah, thanks Tim. I think I understand what you are saying. That’s good to know.
With my software it’s not that critical. I think.
The Arrow + Modifier Keys change the value of a pointer to an array index/element. I’ve just tested the best I can, to quickly strike the keyboard with many random situations - sometimes with my fist 
:). The pointer still holds true.
If it didn’t, I would be shocked and likely give up programming altogether.
Others have different requirements. This is what makes it difficult.