Urgent: GetChar() and XT9
Monkey Forums/Monkey Bug Reports/Urgent: GetChar() and XT9
| ||
| Hy Mark, sorry but very urgent for me (and perhaps for all of us).... http://www.monkeycoder.co.nz/Community/posts.php?topic=7610 |
| ||
| (Yet again, I kick myself for attempting native soft keyboard support, esp. on Android with it's 1001 custom per-device keyboards...) Anyway, you haven't given me enough to go on really - 'some users have problems' is not much use if I can't reproduce the problem. Do these users all have the same brand/model of phone or something? My Nexus 7 doesn't seem to support XT9 at all (or does it?) so I can't even try to reproduce it here right now. There are tweaks you can make to the main.xml file to control predictive text, although these are apparently ignored by some keyboards. If you can narrow down the variables a bit, I might have more luck googling for a solution. |
| ||
| Actually, if you can find out what keyboard they have selected in the language and input settings, it might help - I've got 'Google keyboard' selected. |
| ||
Ok, may have made some progress on this - try inserting this...
//Voodoo to disable predictive text on soft keyboard
public InputConnection onCreateInputConnection( EditorInfo outAttrs ){
outAttrs.inputType=InputType.TYPE_CLASS_TEXT|InputType.TYPE_TEXT_VARIATION_VISIBLE_PASSWORD|InputType.TYPE_TEXT_FLAG_NO_SUGGESTIONS;
return null;
}
...just before the line '//View event handling' (approx line 198 here) in targets/android/modules/native/androidgame.java. I have tried this out with a selection of 3rd party keyboards, and it successfully disables predictive typing on all of them (although some had it disabled to start with for unknown reasons). The bad news is there are reports around of some keyboards ignoring this, but perhaps there are other settings that can be used for these. May be a trial and error thing, so if you run into a particular keyboard not working, try and find out which one it is exactly... |
| ||
| Hello Mark, thanks for starting immediately. I'm not talking about any exotic keyboard, but the default "on screen" virtual keyboards on samsung devices. I have reports from... - Samsung S5300 with Android 2.3 default keyboard. - Samsung Galaxy Note 1 with 4.1.2 - Samsung Galaxy Nexus, Stock, Android 4.3, Root, Kii Keyboard and Google Keyboard don't work. On all of them the demo code does not work. I think it is a general Samsung related problem and affects all Samsung devices. As I believe this is a substancial problem, we should call the community to investigate more about it... I will try to add the workaround an see what happens.... *** EDIT **** It will not work. Already the compiler has a code problem: |
| ||
| > It will not work. Already the compiler has a code problem: Ok, you need an import too. Just grab this instead: https://raw.github.com/blitz-research/monkey/develop/targets/android/modules/native/androidgame.java |
| ||
| Hello Mark, I tested the new android.java and it seems to work in the demo code. I will now add the changes to the game and listen to the feedback of the users. I will get back to you... By the way.... with this changes the virtual keyboard shows not longer these popup umlaut selection, but only one character appears on a key. Before the changes I always could see special selection popup of upto 5 european umlauts like "Ü" when I pressed a <U>. It was not possible to choose one of them, but they were visible.  Do you see a chance to add a feature, where the app waits for the final selection instead of taking the first character immediately? European an russian market often needs this additional characters to write user names, etc... |
| ||
| > Do you see a chance to add a feature, where the app waits for the final selection instead of taking the first character immediately? Well, that did actually work for me with the 3rd party keyboards I tried - nothing was sent to the app until 'space' or 'return' was hit. I thought this is what you were having problems with in the first place... The reason the umlauts have gone is probably because I had to force the input type to be 'visible password' - this was the only was I could convince ALL 3rd party keyboards to disable predictive text. But really, there's only so much kludging I can do here - if you want 'proper' text input, you're probably best to use some kind on native 'text input' dialog that contains a real text widget. |
| ||
| hi Mark, thank you for your quick answer, but I have new problems for you.... The last "androidgame.java" is from V75?, or?. So, to test the workaround in my game I had to transfer the game code from V71 to V75. Now I have another compiler problem with Class AsyncSoundLoaderThread: Class AsyncSoundLoaderThread Extends BBThread="BBAsyncSoundLoaderThread" .... "C:/Monkey_75/bin/transcc_winnt" -target=Html5_Game -config=Debug -run "C:/Monkey/Ballerburg/BallerBurg.monkey" TRANS monkey compiler V1.56 Parsing... Semanting... C:/Monkey_75/modules/mojo/asyncsoundloader.monkey<17> : Error : BBThread is private. Done. Strange, because I do not use the async sound loading feature... I only use normal LoadSound() and PlayMusic() and async image loading. Of course I deleted the build folders. XT9: Did you mix up two different things? XT9 has nothing to do with umlaut selection. XT9 is a feature to complete words or to predict them. When switched on, Monkey is not able to receive GetChar()and I think KeyHit() does not work too. A Samsung device in german language mode with de-activated XT9 still has this umlaut selection. The final app receives single characters, like "a" or "ä". This umlaut selection never worked in any version of monkey. Irrespective from XT9 switched on or off. What do you mean with "3rd party keyboards"? I'm always talking about the build in Samsung onscreen default keyboard. I'm wondering that nobody else did report such problems. Do they have other ways to input texts? Do they really use a native textbox and receive the complete text, when closing it? |
| ||
| The androidgame.java fix above really just needs an 'import android.text.*;' added to the imports at the top - try this with your version. Otherwise, wait for next release. My method for disabling predictive text also has the side effect of disabling umlauts - but this is the only method I could find that worked on all the 3rd party keyboards I tested. Other methods worked without disabling umlauts, but not on all keyboards. By 3rd party keyboards, I mean 'non-stock-android' keyboards, eg: keyboards you can download from googleplay, or samsung/LG etc 'default' keyboards. There are a LOT of 3rd party keyboards, and they all work subtly differently. My reference device is a nexus 7 running stock Android, which I consider to be '1st party' as it's a google device. I'm also a little confused about the problem you're actually having - here, predictive text only delays chars until 'space' or 'return' is hit. It still 'works' in a sense. Are you not receiving ANY chars even when space/return are hit? |
| ||
| hi mark, it's not a problem for me to wait for the next version. I added both changes into "androidgame.java" V71and my app started perfect. No need for hurry, because at the moment I would prefer a solution with a native text input function. What I wanted to say is, that I maybe stumbled over a new V75 bug "Class AsyncSoundLoaderThread"? It has nothing to do with my code and is not related to the keyboard problem.... I can try to demonstrate the bug in an minimum code sample if you where not able to simulate it. I will send it to you... Now I understand "3rd party keyboard" mean also the original samsung keyboard because it is not the original "android" one. Thank you. Again back to XT9: with your workaround a monkey app now returns perfect single characters each time I press a key on the keyboard. Without the workaround it seems to work without any logic. It is not waitung for SPACE or RETURN, but sometimes it send a character I pressed, then it sends 10 times nothing, then send two character when I pressed one. It sends one of the previous A-Z character when I press a number key, but not the number and so on... |
| ||
| hi mark, in additional tests the reported "Class AsyncSoundLoaderThread" bug did not appear again. So it seems to be no bug. Sorry for reporting it... |
   |