[fixed]key input

[zerochen]

hi,

i used svn trunk. win 7 64 bit

i found 2 problems:

first:
in windows:
if i push a key 2 events are fired
eg:
event: key: 97 char: 49 down: yes
event: key: 97 char: 0 down: no

on the up event char is zero. i would guess that it is bug because in linux the char value is the same as the down event.
i think the error is in the scanCode var that is passed in ToAsciiEx in CIrrDeviceWin32.cpp line 801

from http://msdn.microsoft.com/en-us/library ... 85%29.aspx:
"In some cases, however, bit 15 of the uScanCode parameter may be used to distinguish between a key press and a key release"

but it doesnt say something about bit 16 and if that bit is set ToAsciiEx returns 0.
if i would add scanCode &= 0x7FFF; (sets 16th bit to zero) before ToAsciiEx it works like in linux.

second:
in linux:
2 other user reported that the numpad isnt returning numpad0+9 events (of cause if the numpad is on^^). instead of it returns the keys as the numpad is off
here is the output of same test cases
http://pastebin.com/JDmV2eVw
cant test it. maybe needs more investigation...


regards
zerochen

[CuteAlien]

Ok, debugged the one on Linux a little bit and know at least what's wrong now. It does set the correct char - but it also set's the key for left/right/up/down/start/end/pageup/pagedown. And the editbox interprets those first. Not sure right now how that is handled on Windows, have to reboot and check that when I got more time. But I remember a related problem report on Windows that there it isn't possible right now to distinguish between the normal enter key and the one on the num-lock block because lparam values are ignored.

I suppose the correct value for Key would be KEY_NUMPAD0-KEY_NUMPAD9. Because Key should really pass on the key pressed so it can be used for gaming-keys. And then we have to figure out how to get stuff like KEY_LEFT and KEY_HOME from that when num-lock is not pressed in the editbox. Which means either we add another variable (InterpretedKey?) or pass on the num-lock state and handle that in the editbox (which I think is bad). A third solution would be ignoring stuff like KEY_HOME when char is not 0 (maybe the easiest workaround, but I don't think it's really the correct solution).

Or maybe someone has another idea?

edit: On another but related note - working with unicode solution would also be nicer I guess (but takes a little work as it needs some XIC first). And currently noticing that mobile phones are working completely different again as well (which makes me consider currently also adding something like a NativeKeyCode thing or so additionally so people can get the real values no matter what we do with it).

[zerochen]

isnt that line wrong?

Code: Select all

event.xkey.state = 0; // ignore shift-ctrl states for figuring out the key

it resets all keys like strg, control and numlock. (CIrrDeviceLinux.cpp line 1064)

[CuteAlien]

I thought that as well first - but it seems to reset only strg and control - but not numlock. At least according to the documentation I found (X11 docs can be hard to read...).

I also tried adding the workaround by handling some special-key in the editbox only when Char is 0. But then EditBox needs to know _which_ keys do set char to 0. Which I already noticed is not identical between Windows and Linux (for delete key) and might be different again on other systems (can't even test OS X here). And is ugly anyway as this shouldn't be handled there.

[hendu]

Numlock and caps lock are also shown in the state field. You can easily test this with xev.

However, the symbol passed the correct one (keypad 7 vs home), so nulling the state shouldn't hurt.

[CuteAlien]

Not saying it isn't... just that there is no flag mentioned about that in the documentation. I found some hints already that there is some bit set... trying to figure that out currently. X11 documentation sucks nearly as bad as X11 itself *sigh*

[zerochen]

thought that as well first - but it seems to reset only strg and control - but not numlock. At least according to the documentation I found (X11 docs can be hard to read...).

but this Site says:
"The state member is set to indicate the logical state of the pointer buttons and modifier keys just prior to the event, which is the bitwise inclusive OR of one or more of the button or modifier key masks: Button1Mask, Button2Mask, Button3Mask, Button4Mask, Button5Mask, ShiftMask, LockMask, ControlMask, Mod1Mask, Mod2Mask, Mod3Mask, Mod4Mask, and Mod5Mask."

so LockMask seams to be the numlock key?

[CuteAlien]

Hm, that could be. I thought that refers to shift-lock. Will try, but have to fix my system first (Linux system crashing regularly when working with Irrlicht.. probably some driver trouble).

[CuteAlien]

Ok, that was it indeed. Damn - removing that line was the first test I did and when it didn't change anything I looked around for all kind of other solutions. But seems I just forgot linking the updated lib with my test-program *sigh*. poop happens.

Anyway - I reset now only shift+ctrl bits and it seems to work. Checked in as r4669.

[CuteAlien]

Ok, I don't get why bit 16 needs to be cleared, but testing it here I get the same results as you - just works when that one is cleared. So applied your patch for Windows as well. Thanks.

[MyGrandpaWheels]

Excuse me, I'm new to Irrlicht and I'm a bit slow on the uptake.
I have exactly this problem, but I don't understand how to patch it
I work on a Linux platform, Irrlicht 1.8, I have a editbox and I can't input numbers by the keypad..

could someone tell me in a simple manner what i must do?
Many Many thanks!

[CuteAlien]

The easist solution is probably to switch to svn trunk as changing this means re-compiling the engine anyway. svn trunk is the current developer version, but it's (usually) stable (aka - I work with it myself in a professional project right now).
See here how to get it: http://sourceforge.net/p/irrlicht/code/HEAD/tree/
You need to have subversion installed (svn is the subversion client).

To re-compile the engine go into source/Irrlicht folder and type "make". Or install the code::blocks IDE and use the project file in the same folder.

[MyGrandpaWheels]

Many thanks, really clear!
I didn't understand that in the developer version it was fixed.
By the way, Irrlicht is so good: powerful and simple!

Bye..

[MyGrandpaWheels]

..but I can't understand where I'm failing.
well, first of all, I downloaded a snapshot of irrlicht 1.9, just to avoid installing SVN; on the other hand, the compiling worked like a charm.
In my IDE (NetBeans) I updated the include directory and the linked library to the new directory of the 1.9

Full of hope, I rebuilt my project: ok; tried to execute, but soon I had a segmentation fault.
It seems that the problem is about the only camera scene node I'm using.

This is the code I used successfully until now:

Code: Select all

 
ICameraSceneNode *CameraSceneNode = device->getSceneManager()->addCameraSceneNode();
CameraSceneNode->setPosition(vector3df(0, 0, 30));
CameraSceneNode->setTarget(vector3df(0, 0, 0));

The fatal error occur on the second line, CameraSceneNode->setPosition(vector3df(0, 0, 30));

I tried to work around in some way: originally this code was in the constructor of a class, so I tried to put it in the main, but no way.

Could someone help me, please?

[MyGrandpaWheels]

..but I can't understand where I'm failing.

The fatal error occur on the second line, CameraSceneNode->setPosition(vector3df(0, 0, 30));

sorry, not this line: the next, I mean

CameraSceneNode->setTarget(vector3df(0, 0, 0));

Excuse me