[General Topics] Menneisyys:
1.1.1	On-screen dialpads – are they of any use?

As has already been mentioned, one of the 4pda tutorials (original (volta_john, 26.11.06 10:19:44); Babelfish; Google Translate) recommends installing on-screen dialpads for inputting numerals. I don’t think this is a good idea. First, you’ll need to run significantly smaller MIDlets than the native resolution of your screen so that the active MIDlet area and the always-displayed keyboard don’t overlap. This means you’ll need to stick to (at most) 176*220 MIDlets on your QVGA and QVGA or 352*416 (the hi-res version of Nokia’s traditional 176*208 screen) titles on your VGA Pocket PC’s. And, of course, you won’t be able to run MIDlets that stretch themselves dynamically to fill in the entire screen. This alone would make you forget the entire thing. Second, you’ll need to click on-screen buttons instead of just pressing the D-pad directions – as you otherwise would prefer. A pretty awkward way to control particularly games, isn’t it?

Note that you can avoid having to stick to significantly smaller MIDlets than your screen estate really is if you, as opposed to what the 4Pda tutorial recommends, a numeric input panel (or, if you don't mind the horizontal layout in no way representing a real phonepad) only brought up when necessary. I recommend assigning it to a hardware button (just assign <Input Panel> to a hardware app button in Settings / Buttons; this doesn't even require that you read and understand the Button Enhancer Bible); this will be particularly important with MIDlet managers that, on Pocket PC's, don't dispay the bottom bar and/or the icon to bring up the on-screen input panel any time (not only when a text input field has the focus.)

1.1.2 A full chart of all MIDlet manager scan/character codes & the return values of getGameAction()

I’ve also written a small MIDlet to display what the passed code before and after the getGameAction()-based translation are. As usual, I also provide you with the source of the MIDlet. The deployable JAR file is HERE. It’ll, first, display the numeric, and, then, the symbolic name of the return value of getGameAction(); finally, the original, unprocessed, original keycode. It also makes the system dynamically assign "Exit" to one of the two softkeys; the scancode of the other softkey (and, with Jblend, also the one which results in exiting; this is because of the differences in the callback processing order) will be displayed.

For example, upon pressing "2" on the dialpad, hardware or on-screen keyboard, if you see "1: UP: 50" printed on the screen, this means the following: getGameAction() returned the integer 1, which corresponds to the constant "UP". The original character code (it’s a positive number; therefore, it’s a real ASCII character code) 50 ("2" in ASCII). This is what you will see in all cases, with all MIDlet managers, except IBM J9, where this button, as with all other keypad numeric buttons, are unhandled and, therefore, no matter what numeric dialpad button you press, getGameAction() returns 0 ("Unknown"). Yes, you’ve read this right: the dialpad handling in IBM J9 is severely messed up: IBM J9 can ONLY be controlled via the D-pad, unlike with all the other MIDlet managers.

If you press the button 1, "0: Unknown: 49" means getGameAction() returned 0, which corresponds to the unhandled (unknown) case and the original character ASCII code was 49. This is the case with all MIDlet managers except Esmertec’s managers and Jblend, which assign one of the four gaming buttons, GAME_A, to the first dialpad button.

If you press the up direction on your D-pad, you’ll see the following with all MIDlet managers except TAO (the latter uses special scancodes):

"1: UP: -1"

This means getGameAction() returns 1, which, as we’ve already seen, corresponds to the "UP" symbolic constant. Finally, the scancode (it’s negative so it’s not a "real" character code) of the given D-pad direction is -1.

As has already been stated, TAO is behaving differently in this case (too); it’ll return

"1: UP: -57377"

instead. This, as has already been pointed out, is caused by TAO’s using entirely different scancodes than all the other MIDlet managers. Fortunately, this is correctly translated by getGameAction(). Still, if you try to play a game (for example, the already-mentioned Micro Counter Strike 3D Beta) that doesn’t give a call to getGameAction() but directly parses the actual argument of the keyboard handler (for "up", the ASCII code (50) of the dialpad 2 and/or the D-pad "up" scancode -1), it will most likely not work under TAO.

Note that the chart below, which shows how the different Windows Mobile (and, in addition, as a well-implemented, high-quality reference, the MIDlet manager coming with the Nokia’s current top-of-the-line, flagship model, the N95 and its newer versions like the N95-3 and the N95 8GB) MIDlet managers fare in this respect. Now, based on all explanations above, you’ll be able to understand what this all means.

1.2 Strictly softkey issues & JavaMagic results

OK, now, from the D-pad and dialpad-related questions, let’s move on to the question of the WM5 softkeys. As you’ve probably realized if you’ve ever tried to deploy MIDlets under TAO, the right/left softkeys simply won’t work with most of them.

Note that the 4pda.ru folks state the TAO 11.x series, finally, fixed at least the softkey problems (as opposed to the 10.1 series); in this regard, I don’t think they are right.) Unfortunately, this is impossible to fix using the same method as above - that is, just assigning a scancode generator to the two soft buttons with a softkey-assignment-capable button enhancer or, if you don’t necessarily want them to be assigned to hardware softkeys, with any button enhancer – and even the built-in Buttons settings applet. The sole reason for this is that MortScript is only able to pass positive "scancodes" (that is, real characters) and the other two solutions, namely, PQzII and VJKeyPress, aren’t able to pass these particular scancodes either.

Unfortunately, these softkeys,

with several MIDlet managers (namely, the one coming with the Nokia N95, IBM J9, later – non-M3G-enabled – Esmertec Jeodek versions and TAO running on Pocket PC’s (but not on Smartphones)) don’t cause a callback to keyPressed() and,

in the rest of the MIDlet managers (that is, the ones where keyPressed() is called back) getGameAction() returns zero ("Unknown") upon trying to identifying them,

unlike with "traditional" direction, action and/or fire buttons where getGameAction() is the preferred way to see what really has happened and to guarantee compatibility with as many different MIDlet managers as possible. This all means MIDlets themselves must deal with direct scancodes and there're no helper methods (no getGameAction()-alikes) to guarantee cross-KVM compliance. As these codes are pretty much standardized, they have no problems with the Nokia / Esmertec / Jblend ones; this is why they do work. TAO, on the other hand, is, again, an exception, as it uses vastly different scancodes than any else MIDlet manager. This is why the softkeys of the vast majority of MIDlets, unless they have specifically been developed keeping TAO compliance in mind (the case with high-quality business / productivity apps like Opera Mini, the Gmail MIDlet etc.), will NOT work under TAO.