InputTypes

Roger Garstang

Well-Known Member
Licensed User
Longtime User
Been experimenting with InputTypes today and found some interesting stuff:

TYPE_TEXT_VARIATION_PASSWORD behaves how I expect with hiding the password as I type and only showing the letter for a second then hiding it as well as hiding it when keyboard closed. I'm not sure what the PasswordMode option does, but it isn't working for passwords the way I expect with only hiding it when keyboard is closed. It seems to draw the dots different too. TYPE_TEXT_VARIATION_VISIBLE_PASSWORD appears to do nothing on my devices, but sounds like it describes what PasswordMode is doing. May want to just add the input type that operates more standard than a separate option, or maybe in addition to the options for those that like the Visible Passwords PasswordMode does.

I tested every one of the InputTypes in Google's list...most of which weren't very useful or didn't do anything. The DateTime Class is completely missing from the Edit Views in B4A, but seems to be the same as Number for the most part. A few would be very useful to integrate into the B4A Edit controls-

1. Signed Numbers and Signed Decimals
2. Email Address
3. URI/URL
4. Password (Mentioned Above)
5. Cap Chars/Sentences/Words

Some others in Google's list initially got me excited, but then let down once I tried them. Person_Name to me should operate like Cap Words with primary suggestions from Contacts or something, but didn't appear to. The 5-8 things above would be the best of them to have built-in though, and possibly Flag_No_Suggestions (My phone likes suggestions a lot and thinks I mean them instead of what I'm typing).
 
Last edited:

Roger Garstang

Well-Known Member
Licensed User
Longtime User
Found out something else interesting I thought was odd behavior-

If you set InputType to 129 (Password Variation) it hides the text in the control and keyboard. If you don't set it in InputType and instead use IME.SetCustomFilter to set the default it hides it in the full screen keyboard and shows the text in the control or in Portrait keyboard where control is visible.

Seems kind of redundant that both are needed for full effect if you want to filter the password chars. Also odd that putting it in InputType changes how the control is drawn, but using an InputType flag like Cap_Characters doesn't change how the control is drawn...only the keyboard (And it doesn't even catch everything and allows lowercase, so you still need to filter or convert touppercase in TextChanged. Seems like they should have designed Android with styles for the controls instead of the keyboard (Windows has Uppercase and Password styles for Edit Boxes)
 
Top