Found this, it seems related
http://forums.libsdl.org/viewtopic.php?t=8590
it might be a bug of libSDL (which i guess openMSX uses) or a weird behaviour of Windows itself...
Unfortunately switching to the US keyboard layout to me makes things even worse since several chars are then displaced and the only way i have to find them out is to actually try them all one by one...
I'll have to keep my little "hack" (use F6 and F7 instead) which is simpler than having to remember the US keyboard layout.
One little note for the maintainers of the openMSX website... here:
http://openmsx.sourceforge.net/manual/commands.html#bind
it says that i can bind a to a command... but it is not clear which names the can have.
It would be useful to have a link to a table with all the possible names (such as F6, F7, MENU, PAGEUP, ...)
Also, if i wanted to store my "hack" (the bind commands) in a permanent way so that i don't have to re-type it all at each start... where should i write the commands?
Found this too:
http://blogs.msdn.com/b/oldnewthing/archive/2004/03/29/10112...
so it seems that ALTGR is actually CTRL+RALT on Windows, unfortunately i do not have RALT (ALTGR takes its place) so i cannot test if ALTGR+E == CTRL+RALT+E == € or other combinations.
On our keyboards it is just a single key, where RALT is on US keyboards. We use it to access special chars such as € [ ] # @ and others.
Also, if i wanted to store my "hack" (the bind commands) in a permanent way so that i don't have to re-type it all at each start... where should i write the commands?
I answer to myself to this... the changes are permanent already.
I have been able to reproduce the problem under Vista.
The issue is indeed with SDL or windows which generate a CTRL and ALT keypress at the same moment that the character key press is passed to openMSX. Therefore, the MSX rom does not simply see you pressing the [ key but it sees you pressing CTRL and the [ key at the same time and that is indeed meaningless to an MSX.
I guess it requires a fix in SDL so that SDL on Windows will behave the same as SDL on Linux (e.g. pass the RMODE key code when user presses alt-gr)
I have read the SDL thread mentioned a few posts above and it is indeed an issue with Windows itself. Windows maps alt-gr to CTRL+RALT. Reason for this strange mapping is that not all keyboards have a physical alt-gr key. Instead of accepting this fact, Microsoft has tried to make the non-existence of this key on some keyboards transparent to application developers by reversing the logic; Microsoft has decided that pressing the alt-gr key on the physical keyboard will be mapped by Windows to pressing the physical keys CTRL+RALT at the same time. In this manner, applications that wish to detect that a user presses alt-gr can check for CTRL+RALT at the same time being pressed so that users can emulate pressing alt-gr on any keyboard. However, by taking this strange decision, applications are no longer able to distinct between users pressing the physical alt-gr key versus users pressing CTRL and RALT at the same time...
Unfortunately SDL on windows does not revert this back to the real underlying keypress but simply passes on what it receives from Windows. It also does not invoke more low-level Windows APIs to find the real physical keypress (those APIs apparently do exist, see http://molecularmusings.wordpress.com/2011/09/05/properly-ha...)
Well.. that thread is from 2012... if they did nothing to fix it up to now they probably just don't care or think that it is a minor problem (which IMO isn't) or think that it is a windows problem that Microsoft should fix (good luck with that).
Is there anyone here who knows C that has some spare time and could look at it, make and send a patch to libSDL (which i think is the best solution) or patch openMSX to interpret the sequence as AltGr?
Anyways, for me the "big" problem was the square brackets... by binding them to F6 and F7 i pretty much fixed it... but there could be others with more important keys unreachable without a proper fix to this problem.