I am rewriting Lemon Launcher (http://lemonlauncher.sourceforge.net/) using juce. It is a project I gave up on about 3 years ago. It is a front end for mame when it is running in an arcade machine, no keyboard, just joysticks and buttons hooked up throught the keyboard interface.
I’ve encountered a problem, I need to be able to detect key presses of keys like ctrl, shift, alt, etc, but Component::keyPressed() doesn’t get called for these keys. Is there another way to do it?
Windows/Linux itself (as far as I’ve seen) does not pass those. You may want to use sdl (b** to setup for just input), or DirectInput (a b* to deal with, but easy to setup, and windows only). You may want to see if OIS (Open Input System) would be good for you, it wraps a few different styles so you don’t deal with it, but it was made for a game engine so you may need to strip some things out.
You’re not going to have a portable way of doing this. Under Windows, you have several choices. Like OvermindDL1 said, within Win32 you could use DirectInput or you can also use RawInput (Windows XP only). Perhaps the easiest way if you’re using JUCE is to set up a timer loop that polls the Win32 API GetKeyState() directly, then broadcasts an action message to your listener window. If you need super accuracy, then create a thread (with a lower priority than the rest of your app) that does nothing but poll GetKeyState continuously, then broadcasts an action message when the key state changes. You can do the same thing under Linux by reading the keyboard driver directly with ioctl(0, KDSKBMODE, K_RAW) and parsing the scancodes.
It already does this, on all platforms… Component::modifierKeysChanged().
Strange that none of you noticed this method - what could I have put in the help that would have made it easier to find?
[quote=“jules”]It already does this, on all platforms… Component::modifierKeysChanged().
Strange that none of you noticed this method - what could I have put in the help that would have made it easier to find?[/quote]
yep. i’m telling you guys. stealth features. heaps of them.
jules, how many users do you have? you could do a book. i suppose its too much of a moving target.
we need that wiki guys!
I did notice that. I believe the OP was asking for a way to respond to alt, ctrl, or shift being pressed via an interrupt. It does no good in games to have to wait until a window message is received, especially if one can only receive it in the window with the focus. Polling, (or using DI or RawInput), allows one to respond to key input in realtime, in the background, and send that input to any part of the application regardless of which window is active/has the focus.
Ah, I just noticed ModifierKeys::getCurrentModifiersRealtime(). All right, scratch my previous suggestion of using GetKeyState/ioctl in the polling routine and use this directly. I think polling and using getCurrentModifiersRealtime in a lower priority thread will give enough realtime response without requiring a true ISR via DI or RawInput.
And of course, now that I’ve actually gone to the Sourceforge site to see exactly what the OP is using this for, I notice that it’s actually for a UI rather than for any game input.
I see “MAME” in the post and I automatically assume he’s writing a game app of some sort. That’ll teach me to jump (pole vault) to conclusions.