Wrecked Games

Please login or register.

Login with username, password and session length
Advanced search  

News:

We're just that awesome.

Author Topic: default behavior for command sequences  (Read 1285 times)

cdsnyder

  • Regular
  • *
  • Karma: +0/-0
  • Posts: 26
    • View Profile
default behavior for command sequences
« on: February 18, 2006, 01:09:31 PM »

I'm just wondering if in the other OS implimentations, if command key sequences are allowed to continue or if the Keyboard class intercepts them before the OS gets a hold of them. For example, the command-Q in mac will send the quit command event even though I am capturing keyboard input (OSX must have first crack at command sequences before calling my listener). I can register a listener for WindowCommand events and ignore them thus enabling sequences like command-Q or command-C in a game without invoking the quit or copy commands in the OS. Is this something I should enable by default but allow overriding with a parameter in the ParamList?
Logged

cdsnyder

  • Regular
  • *
  • Karma: +0/-0
  • Posts: 26
    • View Profile
default behavior for command sequences
« Reply #1 on: February 18, 2006, 01:21:14 PM »

Err.. now that I think about it.. maybe disable only a subset of command sequences. Disabling all of them would mean no switching tasks and would pretty much lock people up in the event of a full screen crash or infinite loop problem.
Logged

pjcast

  • Administrator
  • Veteran
  • *****
  • Karma: +1/-0
  • Posts: 2661
    • View Profile
    • http://www.wreckedgames.com
default behavior for command sequences
« Reply #2 on: February 18, 2006, 01:37:05 PM »

It is possible in DirectX to disable the Windows logo key (activates start menu), but I believe the default is enabled. Perhaps that should be disabled by default though, since it is so close to the Ctrl Alt and shift keys that it would suck to push that in the middle of an action online game and lose window focus.. Or in the case of full screen mode a complete window minimize. Linux has no notion of these kind of keys.

The linux version of OIS creates an AltTab combine internally to release the mouse and keybaord grab so that users can switch out of the app. There would be no other way to release the lock from the aspect of the user.

So, If that key is easily pressed like the windows logo key, it should probably be disabled so that no acidental focus changes happen.. but, something like a deliberate (or at least hard to do) Alt-Tab event should change app focus, or release control of the Keyboard so multitasking is still available.
Logged

cdsnyder

  • Regular
  • *
  • Karma: +0/-0
  • Posts: 26
    • View Profile
default behavior for command sequences
« Reply #3 on: February 18, 2006, 02:02:10 PM »

Ok. The only one that might be easy to hit and have large ramifications is the quit sequence.. command-q. In windows  it would be near impossible to hit by accident as alt-f4 (iirc). The q is dangerously close to the wasd controls and is usually assigned to lean or something in FPS and command is pretty easy to hit too. I guess I'll just keep it in mind, and decide later. It wouldn't be so bad except that it completely closes the application if you hit it :P Unless of course if the programmer handles it themself.
Logged