FreeOrion

And finally yet another glitch I noticed: When typing in the chat edit control in the message window, "+" and "-" on the numeric keypad don't get you the chars typed, but instead trigger the zoom-in and zoom-out functions in the galaxy window. This doesn't happen in the other edit controls I used for my tests. My guess is that these keys get caught by a galaxy window event handler, so the chat edit control event handler does not get to see it. The other edit controls I used for testing were part of modal dialogs, that would explain why no other event handler could interfere.

Does this happen with and without the numlock patch?

Yes. This phenomen apparently has nothing to do with your patch.

I investigated the issue further, and discovered another key that triggers a similar behaviour. It's the key left of "1", above the TAB and below the ESC key. On my keybord (german QWERTZ keybord layout) it's the key for the "^" and the "°" (with SHIFT). Pressing this key without SHIFT in an edit control in FO produces no characters (even when pressing it multiple times), but every other key I press afterwards is repeated 9 times - except for the vowel keys (a, e, i, o, u). Pressing one of them after pressing "^" produces just one char. "+" and "=" show exactly the same behavious , the only difference is that these actually do produce characters after a first keystroke that produces nothing.

Pressing this key with SHIFT does nothing at all. No characters, no strange behaviour of other keys afterwards, nothing.

Interestingly enough, these keys have a special function on a german keyboard. The key which has the "+" and "=" characters on US keyboards has the accent chars "´" and "`" on it. Normally, when I press one of these keys and a vowel directly afterwards, I don't get two chars (the accent and the vowel), but one: the vowel with the accent above. Example: "â", "é", etc. Pressing a non vowel key afterwards produces two chars. Example: "^h", "´7" etc.

Now this works in every application that handles my german keyboard according to the settings in my system preferences. In FO there is the problem that apparently the keyboard layout settings in the system preferences are ignored, I get a US keyboard layout in FO (which of course is a bit annoying, Y and Z are swapped and most of the special characters are on different keys, fortunately typing text isn't something you have to do a lot in FO ). Obviously the system keyboard settings aren't completely ignored, as the keys that have this special behaviour on german keyboards (to produce accented vowels) seem to interfere with the normal behaviour they have on US keyboards (producing the strange results described above). When I switch the keyboard layout to US in the system preferences, the problem disappears and the keys are working normally.

To me this looks like GG has issues with keyboards other than US, at least on Macs. I'll have a look at the behaviour of these keys on Windows next and report the results.

I think there are some comments in the GG code about assuming a US keyboard layout, or something similar.

Ok, I see.

A quick test with 0.4 on my old XP laptop revealed no issues on Windows. There the keyboard behaves just like an US keyboard does. So apparently this is a OSX specific issue, I guess that maybe this functionality to produce accented vowels is implemented in different OS/driver levels on Windows and OSX, resulting in some kind of interference on OSX that doesn't happen on Windows.

Hi Geoff,

Looks like I wasn't as much out of my depth as I thought. I've given it a try and found out a bit more: The problem seems to be OIS::Keyboard::isKeyDown (which is called in GetModKeys in OISInput.cpp), this function returns true for OIS::KC_LWIN after hiding/unhiding the FO application regardless if the CMD key has been pressed or not.

So I decided to modify GetKeyMods and added a OSX specific code section for querying the mod keys, calling the carbon framework function GetCurrentKeyModifiers instead of OIS::Keyboard::isKeyDown. A few quick tests indicate that this seems to work, hiding/unhiding and minimizing/restoring the FO app no longer results in not being able to type in edit controls.

I made a patch file for OISInput.cpp and attached it. Attention: As I created this diff against GG SVN 1074, also your previous modifications got included.

As this is a contribution for GiGi, what kind of license statement do you need from me? IIRC GG isn't released under the same license as FO...

GiGi is released under the LGPL 2.1 or later (see the note in most of the GG header files), so probably tzlaine would want the same for a patch.

Ok, I release this contribution to GiGi under the LGPL 2.1 license.