You are mixing physical key codes (which is what is delivered in KeyEvent
objects) with generated characters. You really don't want to do that,
because keyboards in different devices will have different (perhaps
radically different) key layouts.
Plus since there is no "tab key" in the G1, I think
Hmmm, that's very interesting. Thank you. As hinted in my original
post, I suspected there was some dichotomy between the physical
keyboard (and its KeyListener) and the higher-level characters being
delivered to the EditText. Thank you.
Nevertheless, I am actually trying to implement a rather
On Wed, Dec 17, 2008 at 9:37 AM, Keith Wiley wrote:
> Nevertheless, I am actually trying to implement a rather common UI
> mantra, where tab jumps to the next edit text (focus right or down or
> something logical like that).
That is only common on desktop UIs. On phones, the user typically nav
On Wed, 2008-12-17 at 16:35 -0800, Dianne Hackborn wrote:
> On Wed, Dec 17, 2008 at 9:37 AM, Keith Wiley
> wrote:
> Nevertheless, I am actually trying to implement a rather
> common UI
> mantra, where tab jumps to the next edit text (focus right or
> down or
>
ARgh...
I use the OnKeyListener to limit a editText to 8 characters ( as
described here :
http://androidblogger.blogspot.com/2008/11/editview-with-limited-number-of.html
)
Do you mean it is a bad idea ?
What would be the correct way to do that ?
Emmanuel
http://androidblogger.blogspot.com/
O
Well, I understand your point, but I'm writing a program in which the
user might be doing lots of data entry into numerous text fields. In
my own testing so far it is much much easier, less error prone, and
generally more efficient to do this with the tab and return keys
instead of the thumb whee
It is seriously easier for them to chord ALT+TAB (both on the left side of
the keyboard making it especially awkward) than to move the trackball? Well
whatever.
But anyway, your code will break on pretty much any other future device than
the G1 -- those that have a different keyboard layout, and
Yeah, it sounds like the best way to implement this behavior is to
avoid the Keyboard level enirely and do it by catching tab characters
as they are appear in the edit text, removing them, reassigning the
previous text to the box, and then performing the desired request
focus on the next edit text
I have not been saying that you shouldn't provide other ways for the user to
navigate and your UI if you want, I have been saying that the implementation
you have been discussing and posting here would break on pretty much
anything besides the G1. At the end of the day, you get to design your app
On Fri, 2008-12-19 at 01:24 -0800, Dianne Hackborn wrote:
> I have not been saying that you shouldn't provide other ways for the
> user to navigate and your UI if you want, I have been saying that the
> implementation you have been discussing and posting here would break
> on pretty much anything
Brian Beattie wrote:
> Why do you say this? It seems to me that this would work on any device
> with a physical keyboard and that Android does not yet provide an on
> screen keyboard most Android devices will provide a physical keyboard.
If I understand the situation correctly, the originally-pr
Keith Wiley wrote:
> Consider the following inefficiency
> that is imposed by using the trackball: You can't necessarily skip
> out of an edit text with the trackball in the desired way because the
> cursor may be in the middle of the edit text, in which case
> trackballing merely moves the curso
Yes, thank you. If I pursue this approach, I do want to try to make
it as general as possible. I think the TextWatcher level will
accomplish that, right?
On Dec 19, 1:24 am, "Dianne Hackborn" wrote:
> I have not been saying that you shouldn't provide other ways for the user to
> navigate and y
On Dec 19, 5:10 am, Mark Murphy wrote:
> KeithWileywrote:
> > Consider the following inefficiency
> > that is imposed by using the trackball: You can't necessarily skip
> > out of an edit text with the trackball in the desired way because the
> > cursor may be in the middle of the edit text, in
Keith Wiley wrote:
> I admit that I haven't look at the note you are referring to,
WikiNotes is a program, for Android. It's available on the Market, and
the source code is in the apps-for-android project:
http://code.google.com/p/apps-for-android/
> If your cursor is in the middle of the text
Yeah TextWatcher is reasonable. You'd end up with the behavior where if the
user enters a tab character through a soft keyboard that your app switches
focus, which might be surprising to users, but wouldn't be broken (as long
as you really don't want any tabs in the field).
On Fri, Dec 19, 2008 a
Thank you for your patience. I do appreciate your advice on the
matter. I will take it under consideration during development.
Cheers!
On Dec 19, 5:50 pm, "Dianne Hackborn" wrote:
> Yeah TextWatcher is reasonable. You'd end up with the behavior where if the
> user enters a tab character thro
17 matches
Mail list logo