Detecting modifier keys held down at startup?


#1

Hello again!

I’m wanting to detect whether modifier keys are held down at startup so the application can “dump its prefs” (just in case someone manages to corrupt the prefs in a bad way).

Unfortunately, both ModifierKeys::getCurrentModifiers() and ModifierKeys::getCurrentModifiersRealTime() return a ModifierKeys with rawKeys = 0 right to the very end of my startup sequence - where I need to either use those prefs, or to trash them and get defaults. I’ve already created my components, displayed them and done everything except resize them. I’m running this on Mac OS/X

If I could get notification when ModifierKeys were ready to read, that’d be fine too!

Any ideas? Debugging this is, as you can imagine, hard… :smiley:


#2

That’s actually a bit tricky, because although it’d be possible on win32, I don’t think it could be done on all plaforms… I’m fairly sure that on OSX, you can’t randomly ask which keys are down, you have to wait for a key-event, so if the event happened before your app started, I think you’re out of luck…


#3

I’m fairly sure that on OSX, you can’t randomly ask which keys are down, you have to wait for a key-event, so if the event happened before your app started, I think you’re out of luck…

Oof! But I’m pretty sure I’ve had programs on the Mac that trashed their preferences when they were started up with certain key combinations held down?

EDIT: some experimentation found no way to detect what modifier keys were down, no matter how long I waited. As long as I didn’t shift my hands on the keys, polling getCurrentModifiersRealtime() got 0 consistently.

OK, then, can you think of some way to signal “Ignore preferences” in start up? This is such a common feature, and for a non-technical audience, telling them to go to a specific directory and delete some files is not a good one.

FURTHER EDIT: I posted this on stackOverflow - please vote it up if you have an account!


#4

if nothing else works, you could at least make your app respond a specific command line parameter


#5

So there has been decided progress on this matter!

StackOverflow seems to know how to do this, at least on the Mac.

There’s code similar to this already in Juce, so my feeling is that if I can cause a call to NSViewComponentPeer::updateModifier or something much like it in applicationDidFinishLaunching then we’re good to go…?


#6

Interesting, I didn’t realise it could do that. In fact I don’t think it’d need to be done inside the applicationDidFinishLaunching callback, you could probably do the same trick anywhere. It’s a very easy change, I’ll check something in…


#7

Yahoo!


#8

FYI: http://www.rawmaterialsoftware.com/viewtopic.php?f=4&t=8254&p=46687#p46687


#9

Gah, phooie!

Well, I moved in other ways anyway, for various reasons. Slightly OT, but here’s what the total solution in the context of my app:

  1. Bullet-proof reading the data files by testing with deliberately corrupt files. I’m using Google protocol buffers which are guaranteed never to crash on corrupted data, but I need to be careful to check all error codes, and to not try to e.g. dereference array elements that aren’t there.

  2. Put a secret “lock” file beside preferences files when I open them, which is only closed when we move to new data or quit the program. If the program gets to a preferences file with a lock, it warns the user and lets them ignore the file, abort the operation, or continue as usual.

  3. Add “clear global preferences” and “clear preferences for this file” menu options.

It’s quite a bit more work, but each part adds to the strength of the program - and you never have to “go to the manual and try to find how to restart the program without prefs”, which is something that most people would never think to do (most users don’t even glance at the manual anyway).