Mobile Key Codes

[LunaRebirth]

Figured this belonged in this section, though I could be wrong.

Basically what's going on is that I have my game that works on Windows and Android.
If I enter in an EditBox on Windows "=" it displays the equals sign without issues.
However, on Android it doesn't seem to find that I've entered the equals button on the virtual keyboard.

This happens to many keys, like: []{}=@#/* etc.

I've tried this to see if it's getting the key codes:

Code: Select all

for (int x = 0; x < KEY_KEY_CODES_COUNT; ++x)
  if (keyIsDown[x])
    print(x);

On Windows it gets all of the keys just fine, like the equals sign will print "187"
On Android, it gets most of the keys just fine, but the keys that aren't working on Android will print "0"

Is there a workaround to this issue or something I can do to fix it?

EDIT:
Similarly, this is printing "0" on Android with mentioned keys (like equals), while other keys like abcdefgh... are printing the correct key code

Code: Select all

bool MyEventReceiver::OnEvent(const SEvent& event)
{
   if (event.EventType == irr::EET_KEY_INPUT_EVENT) {
      char c[255];
      sprintf(c, "Key Pressed: %d", event.KeyInput.Key);
      Game::logger->log(c);
   }
   ...
}

[CuteAlien]

You can check event.KeyInput.SystemKeyCode which should be unique. If you tell me which number it has for which signs I can also improve CIrrDeviceAndroid::createKeyMap() (maybe I can do the tests myself over the week, don't know yet).

I have to admit that at this point I've nearly given up on using the system Android keyboard. I don't get it working in landscape mode since one of the later Android 4 versions. And after debugging it for over a day I'm pretty certain by now it's bug on the Android side. The problem with that is - Google does not care about problems arising in the mix of NDK using SDK functions because their official stance is that they don't support that mix. And they also don't care that their native keyboard functions which they also offer have been broken since the start despite getting lots of reports about those. So in the end - using the system keyboard on Android from the NDK is something Google does not support.

My solution next time will be to write my own keyboard. Not that hard anyway (it's just a bunch of buttons), thought I will lose international support probably (because I'm lazy).

[LunaRebirth]

My Google keyboard didn't work on the Android Irrlicht project until recently the Google keyboard had an update.
Changed the color of my keyboard to white (was hard to get used to) but no longer do I have any issues with it.

I'll try out that solution and get you the numbers when I get off work. Thanks!

[LunaRebirth]

Here are some keys I need from SystemKeyCode to work on EditBoxes:

Code: Select all

@ -> 77
# -> 18
/ -> 76
* -> 17
" -> 75
' -> also 75?
: -> 74
; -> also 74?
? -> also 76?
| -> 73
= -> 70
{ -> 71
} -> 72
\ -> also 73?
[ -> also 71?
] -> also 72?

I believe that's everything I need to work that doesn't

[CuteAlien]

Seems those key-codes depend on the keyboard layout (the return the value of the character that's on the main-keyboard page). So in my case those are all different values. We already call the corresponsing java call to convert to unicode - just seems it's one more of those things that fail when called from the NDK. And as usual there is no NDK function to get the unicode values directly.

Don't know how to fix that.

[LunaRebirth]

Hmm okay. So is there any way to simulate a key press for an EditBox, for Android?
Like maybe if I could add a []{}etc. character to the EditBox manually Via code?

[CuteAlien]

You can create events with IrrlichtDevice::postEventFromUser. For example I used that code in my game:

Code: Select all

 
 
void IrrlichtManager::SendKeyEvent( irr::EKEY_CODE key_, bool pressedDown_, wchar_t character_)
{
    if ( mIrrlichtDevice && mIrrlichtDevice->getGUIEnvironment() )
    {
        SEvent irrEvent;
        irrEvent.EventType = irr::EET_KEY_INPUT_EVENT;
        irrEvent.KeyInput.PressedDown = pressedDown_;
        irrEvent.KeyInput.Control = false;
        irrEvent.KeyInput.Shift = false;
        irrEvent.KeyInput.Char = character_;
        irrEvent.KeyInput.Key = key_;
 
        if ( mEventReceiver )
            mEventReceiver->OnEvent(irrEvent);
        mIrrlichtDevice->getGUIEnvironment()->postEventFromUser(irrEvent);
    }
}
 

I also have some code where I created an own keyboard, but not sure if it helps you as I use my own gui-stuff in there (so also has a corresponding xml-file with thelayout):
https://bitbucket.org/mzeilfelder/trunk ... ew-default
(It's a bunch of buttons and after loading I assing some mapping to real keys. Also some functions to show/hide it - that's basically it).

[LunaRebirth]

Ah you da bomb.
I'll go ahead and use the SendKeyEvent method for now.
Will make my own keyboard in the future.

Works as a good work-around for now
Thanks!

[CuteAlien]

Reading it now i wonder a little bit why I didn't use IrrlichtDevice::postEventFromUser directly instead of calling my own receiver and then just posting to GUI. Probably something game specific... so could be you can simplify the function a little bit.

[LunaRebirth]

I looked into the source for the GUI EditBox and I'm still kinda wondering why the functions like ::inputChar or ::getLineFromPos are protected.
Personally I could use those in the game I'm building.

Ah well. Maybe one day when I get further into development, I'll edit the source and statically build it.
Wouldn't be a bad idea to tweak with the variables in calculateScrollPos to make a scroll bar.

[Cube_]

I'll just chime in on android NDK: Google doesn't really support it at all, to do anything interesting you need NDK/SDK combo which is unsupported.
So you then have the choice of: native SDK, unsupported mix, or rewriting every SDK behavior you need in NDK. (all of which suck).

[CuteAlien]

@LunaRebirth: Don't know about inputChar right now. The getLineFromPos is protected because the current version is not ready for public. We have some stuff that needs to be fixed open for editbox (basically we need a more general text-wrapper class instead of implementing wrapping x times in Irrlicht and also should ensure in the future that classes like editbox return the same text you put in there without messing with newlines... but that needs a bunch of changes and getLineFromPos is one of the functions that will likely be affected).