Hi Mark, > At the risk of sounding impertinent: why?
My app is aimed at blind users, and individual key presses form a basic means to quickly change operating mode during mobile use, such as to select a color filter by pressing the first character of the color name, or toggle the color identifier, while also speaking the pressed key name for confirmation. Works fine with the G1 hardware keyboard. One does not want to enter complete strings for such quick mode changes, nor navigate a menu (too slow, too inconvenient). Touch gestures might make an alternative, but for consistency, and because I already use touch for other input functions, I just want to emulate the functionality of phones that have a hardware keyboard, and thus respond to individual key presses on the soft keyboard. I now added a "dummy" EditText to my app's main screen as a means for the blind user to pop up the soft keyboard and perform a key press, but was next baffled to find that the soft keyboard functioned as a software keyboard for digits, but not for letters, thus breaking my app on phones that lack a hardware keyboard. Moreover, even when entering strings, the blind user needs speech feedback for each character pressed, to be notified of typos. I hope this clarifies why I am seeking a simple way to pop up the soft keyboard and get events with individual key presses for all the keys that show up on the screen, including all digits and letters. Hopefully such basic functionality is possible without adding a lot of dedicated IME code? Indeed I would not mind using a touch event to pop up the soft keyboard instead of using an EditText, as long as I can next get those individual key presses. Thanks On May 21, 11:31 am, "Mark Murphy" <mmur...@commonsware.com> wrote: > > as I simply want to keep on responding to individual key presses and > > nothing else. > > At the risk of sounding impertinent: why? > > I can see wanting to handle key events outside an EditText, but inside an > EditText, there may be better ways of achieving your application goals > than detecting individual key events. > > Part of the problem is that you have given us a very narrow view on what > you are trying to achieve. What sorts of key events are you trying to trap > and what behavior are you trying to do when those events are raised? > Perhaps by giving people a broader perspective on what you are aiming for, > you can get answers that meet your user experience objectives while also > integrate well with the IMEs. > > -- > Mark Murphy (a Commons Guy)http://commonsware.com > _The Busy Coder's Guide to Android Development_ Version 2.0 Available! --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
