Hi,
I've added a chat to State of Profit and I have a question regarding the keyboard handling.
I have a dutch keyboard with US International settings (default in the Netherlands). When typing ' or " the character don't appear right away but instead they appear when I click on the next item. When clicking first on ' and then on for example u or o I get ú or ó (or ü or ö), when clicking first on ' and then on m I get 'm.
When doing this in lwjgl ' is seen using Keyboard.getEventKey() but not using Keyboard.getEventCharacter() (which is expected behaviour seeing as the character isn't decided yet). When clicking u afterwards getEventKey() sees that I clicked u and getEventCharacter() sees that the character became a ú (expected behavior, so far so good). The problem occurs if I type ' and then for example m (as in I'm). The m in this case is seen with getEventKey() correctly, but getEventCharacter() only shows the ', not the m.
I guess I could create my own getEventCharacter() but that sounds like a lot of work for something that should work already :)
I'm not sure if it's a bug or if I'm using getEventCharacter() incorrectly, help! :)
Mike
After looking into it (thanks Riven!) it appears on several keyboard layouts. if you for example choose the layout for United States-International, the keys ~, ^, ' and " is only displayed after after one extra keystroke, in which case you'll either get two letters appearing, or the special ones ó, î õ, ÿ and so on. I don't know if lwjgl can read two characters when only one keystroke appears (I guess not?) which is why it doesn't work.
If anyone has any ideas I'm all ears.
http://support.microsoft.com/kb/306560/en-us a bit down is an explanation.
Mike
Looks like we need to somehow use WM_DEADCHAR on Windows?
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646277(v=VS.85).aspx (http://msdn.microsoft.com/en-us/library/windows/desktop/ms646277(v=VS.85).aspx)
That looks precisely like it! Is it difficult to pick up those messages?
Mike
I'm not sure how you would incorporate it with WM_CHAR to ignore it though unfortunately, unless WM_DEADCHAR always gets called first. There must be a way...but have no idea right now.
Is there anything I can do to help? I'm not very good in c++ (very rusty even) so I don't think I can mess around in the native code, but if there is something that can be tested in the java part...?
Mike
It sounds like an RFE/Bug, can someone move the thread?
Mike
At a glance I assume that the above is related to the recent RFE for a Text API (http://lwjgl.org/forum/index.php/topic,4129.0.html) ?.
That looks more like support for chinese/japanese. This is for making the lwjgl keyboard work with the US international keyboard layout (which it does not at the moment). It might be that IME support would solve that as well, but supporting the us international keyboard layout is probably a lot easier than supporting IME.
Mike
Hm how much of this is honestly just reinventing the wheel?
Cas :)
Reinventing the wheel? Does lwjgl already work correctly with us international in some other way?
This is what appears LWJGL needs to do....
If I remember correctly, LWJGL uses WM_CHAR, so based this off of that. I didn't test any of this...
WM_CHAR:{
// also may need to stick bit 30 on the end of scanCode to indicate up/down
int scanCode = (lParam>>16)&0xFF;
int virtualKey = MapVirtualKey(scanCode,MAPVK_VSC_TO_VK_EX);
BYTE states[256];
GetKeyboardState(states);
WCHAR buffer[10];
int result = ToUnicode(virtualKey,scanCode,states,buffer,10,0);
if(result < 0) {
// Ignore this key; it's a dead char
}
else {
// Process this key!
}
}break;
This may work; would have to test. Based on research it should. It may be easier to just process WM_KEYDOWN's and translate those with ToUnicode (you don't lose any of the functionality of WM_CHAR I believe).
I hope the equivalent keyboard Linux code works fine for this. I'm probably never going to install another Keyboard layout, so I won't look into suggesting fixed code for that unless it crops up as a bug on the forums.
LWJGL really needs a QA person for each OS haha. And then also a different forum for tracking bugs and posting fixes for each OS.
NOTE: this code is missing necessary checks like if scanCode is 0, etc., that would be necessary for production.
How can I test this? Try to compile lwjgl myself with the change? Is it enough with compiling the jar part?
Quote from: Mickelukas on October 03, 2011, 18:52:31
How can I test this? Try to compile lwjgl myself with the change? Is it enough with compiling the jar part?
yes, its pretty easy to compile lwjgl once you've got the compiler installed, just run build.xml. The jar part isn't going to be enough here as native code is involved. Once the ant script is done running, the new lwjgl.jar is found in the lib folder with the new natives in the lib/windows folder.
Oh, as far as I could see the natives were tricky with visual studio and so on... I'll see if I can figure out how to do it and otherwise look into maybe jinput if they handle the international keyboard correctly (if you can handle keyboard there, never looked at jinput before).
Mike
WRT wheel reinventing... AWT does all this stuff really well, I just don't know whether it's all that useful getting ever more complex input working in LWJGL really... but, well, if it's no bother...
Cas :)
Well, seeing as I can't add keylisteners and have them working with a lwjgl canvas/fullscreen that doesn't really help me now, does it? ;)
Mike