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/ On Dec 17, 4:10 am, "Dianne Hackborn" <hack...@android.com> wrote: > 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 the idea of intercepting > it is a bit questionable. If you just want to prevent tab characters from > being put into the text view, there are various APIs on it that you can use > to monitor changes happening to the text view -- see > addTextChangedListener(). I don't know if you can stop the edit from > happening, though, so you may have to revert things you don't want. > > Also note that when we introduce soft input methods in the near future, the > user will be able to edit in a text view without there being any key events > generated at all... > > > > On Tue, Dec 16, 2008 at 6:41 PM, Keith Wiley <kbwi...@gmail.com> wrote: > > > I would like to intercept the tab key in an EditText. I derived a new > > class from EditText and implemented the OnKeyListener interface. I > > look for event.getAction() == KeyEvent.ACTION_DOWN && keyCode == > > KeyEvent.KEYCODE_TAB, but here is what happens: > > > user presses alt -> action down / keycode alt > > user releasees alt -> action up / keycode alt > > user presses q -> action down / keycode q > > user releases q -> action up / keycode q > > > So, a tab character is never intercepted by OnKeyListener...yet a tab > > will ultimately be deliver to the EditText, so I failed to intercept > > it. Next thing I did was implement my OnKeyListener differently. > > Instead of look for key down and keycode tab I look for key down, > > event alt pressed, and keycode q, as in: > > > user pressed alt -> action down / keycode alt > > user presses q -> action down / event.altpressed true / keycode q > > user releases q > > user releases alt > > > This implementation successfully intercepts an action where the user > > presses and holds alt while pressing q, which would ordinarily deliver > > a tab to the EditText, so that's great, that worked, I intercepted the > > tab. > > > ...but there's two problems with relying on this approach (looking for > > key down, alt pressed, and keycode q). First, it still lets the other > > kind of tab through to the EditText and I want to intercept those tabs > > too. Second, I assume there is no guarantee that on other hardware > > besides the G1 that the tab will correspond to an alt-q in the first > > place, so hard-coding such a test seems inappropriate. > > > What is the solution to this problem? > > > Thank you. > > > Cheers! > > -- > Dianne Hackborn > Android framework engineer > hack...@android.com > > Note: please don't send private questions to me, as I don't have time to > provide private support. All such questions should be posted on public > forums, where I and others can see and answer them. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
