Detecting keypresses before startup
BlitzMax Forums/BlitzMax Programming/Detecting keypresses before startup
| ||
| How can I detect whether a modifier key is being held down while my application starts? It seems that with polled input you can only read the keyboard if there is a window or fullscreen open. How can I read if the keyboard is being pressed in a certain way, prior to opening a window/screen, so that that information can be used to decide what window/screen to open? Do I have to use events? I tried to use PollEvent() and PeekEvent() but they gave a compiler error, something about not being able to compile mark sibly's folder. Is it even possible to sense a key, which is being pressed since before the app even was loaded? If this isn't possible I guess I'll have to have a small startup window with buttons to click to give that functionality? The aim is to force certain screen modes by pressing a key such as CTRL, or shift or alt/option, as the app begins to run. |
| ||
| Does Blitz do a default flushkeys when it starts up, and can this be removed from somewhere? [EDIT] I tried to remove it from PolledInput.bmx but that didn't help because it looks like the system has to be polled before the keypresses can begin to be registered, so it won't recognize keys that were held down prior to executing? It seems that the hook for the events has to wait for an event, and it wont get an event from a pre-existing keypress? |
| ||
| Seems caps lock is not known to be switched on at the start of an app, either, if it was pressed prior to starting the app. Can this be added as a future feature, where if you start the app and caps lock is pressed, it puts a caps lock event into the queue so when you do keydown(KEY_CAPSLOCK) it actually starts out in the on position? |
| ||
| Anyone? |
| ||
| I guess not then. I am thinking I might write to a `success` file, saying "successs=false", before opening a screen, then try to open a screen. If it bombs out and crashes, the next time the game is run it reads the file and if the file says "success=false" that means that last time it ran it couldn't create a screen, ... so then falls into Window mode. I suppose that would be one way of doing it. But it'd be so nice to have detection of keys already being held down since prior to execution. |
| ||
| I think people are trying to find out if it's possible or not. I don't think anyone wants to say it's impossible, because just as soon as someone does, they're proven wrong. However, I'm sure the solution is evading everyone. When you press a key on the keyboard, Windows sends an EVENT_KEYDOWN to the app in focus. Since your app isn't running yet, that EVENT_KEYDOWN will be lost. Basically your app needs to respond to a Windows event before it's even running which it just cannot do. Your best bet would be to create command line switches for your application and have a default window for double-clicks and a person can use the Run dialog if they need to run different modes in your program. |
| ||
| Hey TomToad, thanks for the reply. This reminds me actually that although the system might maintain track of whether shift is being pressed or not, and also for the other modifiers including capslock, it doesn't actually sense that the key is being pressed, it only senses that it `was pressed`, and only recorded a state change when the press first began, regardless of whether it is ongoing, and only changes back when the key is released. So yeah, since it actually deals in keypress events rather than looking at the keyboard and sensing if the key is `being pressed`, I guess there's no real way to detect the overal state of these modifiers. It would be nice to be able to grab the current state from the system, ie since Windows/Mac/Linux is itself keeping track of whether shift is up or down, etc, if Max could get that information and start out with it as its internal state, that would work. But alas I guess this isn't too likely. I think what I will do is my earlier suggestion - write false to a file, try to open fullscreen, if it fails then the next time the app is run it reads the file and finds false there, so it knows to open in a window. I only really need to handle this one situation, even though multiple modifiers would be cool. I don't want to use command line arguments because hardly anyone knows that a command line even exists, let alone how to use it. Is it possible to have the user shift-click in the desktop, clicking on a file and shift clicking on my game app, then have the path of the dummy file pass into Max? If that would work I'd be able to use the dummy file as a `trigger`, ie say `click the "window mode" icon, hold shift and click the game` to run it in window mode? Or, I guess I could distribute two copies of the game, one that runs in a window and one that runs fullscreen? |
| ||
One idea is to use .bat files. Just have a program default to fullscreen, but if they want windowed, they double click on the .bat file which contains the lineAppTitle.exe /w |
| ||
| Doesn't work on mac/linux but its a nice idea. But then you would have separate icons, one for window mode and one for fullscreen. I'd prefer a single icon. |
| ||
| My prefered solution for Windows would be to check Virtualkeys via API at startup. Thats exactly what I've done on Blitz3D to get Capslock and Numlock states at startup. Hm, thats no solution for Linux or Mav, but a first hint. |
| ||
| Thanks but I am focussing on cross-platform development. |
   |