Exactly, I have a few test apps that use this method. So far, the customers love it for key code and password input. You can't mask the keys on the built-in keyboard so your co-workers could watch over your shoulder, masking graffiti input is horrible since few are 100% accurate writing with it. When you require password/key code input, your own number pad can work great and is very GUI friendly(not to mention fewer taps are required so it remains very Palm-Zen)
> > I think you missed the point here. The built-in input functions are > not very well suited for entering passwords. Graffiti is bad > because, if you're masking the input, you don't know if the letter > you wrote is the letter you meant. You can't use the built-in > keyboard because it echoes the characters you type in. > > No one said "replace the builtin keyboard". They said "don't allow > use of the built-in keyboard". There's a subtle difference. When a > user presses the "keyboard" button, they get no keyboard, not a > different one. > > The best method I've seen, used in Secret!(and other apps I'm sure), > is to create an on-screen keypad or keyboard as part of the password > entry form, and provide feedback as to which key was pressed by > flashing it. A keyboard is not a new user paradigm that needs to be > learned. This gives the added advantage that the program could > jumble the keypad every time, giving another level of protection. > = -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
