Thank you, Dianne. I must admit that I find this an utterly confusing
paradigm. So now we have a *software* keyboard that makes a (novel!)
distinction between what *it* considers "physical" keys and "non-
physical" keys? All those digit and letter keys were physical enough
on my ADP slide-out keyboard, and my EditText onKey() example works
perfectly fine there with both digits *and* letters. As a physicist I
am lost here. The user sees either a (truly) physical keyboard or an
on-screen keyboard that gets physically touched, and why must there be
a further split in key types for application programmers? This
artificial split does not even match the non-Qwerty "numeric" keyboard
of basic phones, because for instance the '#' hash/pound key also
fails to raise a key event with the soft keyboard. In short, it all
looks like a design oversight to me.
To be concrete:
With the ADP slide-out keyboard, pressing '7' gives keyCode 14, and
pressing 'a' gives keyCode 29 in my example code. However, with the
ADP soft keyboard, pressing '7' gives keyCode 14, but pressing 'a'
gives... nothing, zilch, no key event at all.
I may be naive but I find this an undesirable complication. IMO I
should not have to add any special InputConnection code to recover
proper default behavior here?
Thanks
On May 21, 3:55 am, Dianne Hackborn <hack...@android.com> wrote:
> Most text isn't delivered through key events, since key events represent
> physical keys and not Unicode characters. The IME sends most of its text
> through the editing with the InputConnection interface.
>
> On Wed, May 20, 2009 at 11:34 AM, blindfold <seeingwithso...@gmail.com>wrote:
>
>
>
>
>
> > Hi,
>
> > I have a regular EditText that nicely pops up the soft keyboard when
> > the hardware keyboard is closed. Entering data also works fine and
> > gets preserved by my app. However, when I try to track individual key
> > presses using the following code,
>
> > EditText myedit;
>
> > // Only gets number keys??
> > myedit.setOnKeyListener(new EditText.OnKeyListener() {
> > �...@override
> > public boolean onKey(View v, int keyCode, KeyEvent event) {
> > Log.i("OIC","keycode "+keyCode);
> > KeyCharacterMap kmap = KeyCharacterMap.load(event.getDeviceId
> > ());
> > if (kmap.isPrintingKey(keyCode) && event.getAction() ==
> > KeyEvent.ACTION_DOWN) {
> > // Blah, blah
> > }
> > return false;
> > }
> > });
>
> > no key presses show up in LogCat *except* for number key presses
> > (0-9). No letters, punctuation, or anything other than numeric digits
> > and a few special keys such as Del and Return. Is this a bug or a
> > feature? In this particular case I am only interested in individual
> > alphabetic key presses, but the listener fails to report them. What's
> > wrong?
>
> > I'm using the official Android 1.5 on my ADP.
>
> > Thanks
>
> --
> Dianne Hackborn
> Android framework engineer
> hack...@android.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
