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 -~----------~----~----~----~------~----~------~--~---
