I'm pretty sure this is an iOS setting. I've shut it off on my iPhone, for instance (along with auto-correct), and it affects my typing in all apps.
You were right Chris, this setting cancelled capitalization.
FMGO v13 apparently does not respond to this as that behaves irrespective of the iPhone settings.
Pity it cannot be defined at program level because it is a useful feature elsewhere.
I think FM Go should have the ability to override that because you can’t expect to be able to do this on everyone’s iPhone. For now I would put a warning above the fields for the users to watch out for capitalization.
Since this is Apple iOS behavior, I wouldn't know how FMI could change this!
you are using a layout instead of a custom-dialog (CD). If you'd use a CD, then you are able to use "Input-field" where "Use password character" can be selected. In those cases the first character is not a capital by default. However it is not possible to have your neat icon in the dialog...
(btw CU @ Office or @ FmSummit?)
@efficientbizz: Actually, there IS an option to override this behaviour as in FMGO v13 it does not happen.
@Menno, thanks, but the CD was just the option I wanted to circumvent. I have added a check when error 212 comes back and the first letter is a capital, the user is warned that caps may be on.
(office; possibly, FMsummit sure)
WHile the setting under Go13 was not iOS like, many user complained - the auto-caps is very helpfull when writing text. On the other hand, it should be possible to define different for a specific field, similar to the keyboard type for a field.
I personally deactivated auto caps in general under FMGo13, just to have identical behavior in all apps (without loving that)
Then how about checking for:
Upper ( Left ( PW ; 1 ) ) & Middle ( PW ; 2 ; Length ( PW ) - 1 ) and for
Lower ( Left ( PW ; 1 ) ) & Middle ( PW ; 2 ; Length ( PW ) - 1 )
You would not have to bother the user with the capitol-char-issue and it would decrease the security only in a minor way, wouldn't it?
Close, I am using a CF to flag a warning:
Let ( [
char = Left ( text ; 1 ) ;
capital = Case ( Code ( char ) ≥ 65 and Code ( char ) ≤ 90 ; 1 )
But the users pw's are already set and stored as MD5 hash in the main solution, so I don't know if there is a first cap.
I don't want to bother them with a change pw request, so I just check before the hash is set, then flag a warning when an error 212 is returned during login.
I understand, but I meant it like that you'd take the users entry and send taht in 2 requests to your check: one with with and one wwithout the first character as a capital, so only if both queries have a different result, they have entered the correct password.
good point, I will integrate that in the script.
ariley, I wholeheartedly agree. We need the option to have a field that accepts exactly what is typed, without assuming we want capitalization. This works fine for fields that accept sentences, but I have many cases where I have fields that accept serial numbers, codes, etc that may or may not begin with a capital, needing to hit the shift key to "un-capitalize" is not intuitive. And, like psijmons, I have solutions with fields I use as masked password fields, where it is completely absurd to have auto capitalization. efficientbizz- I develop apps for iOS in different platforms, and iOS does not restrict you to this behavior, you have the ability to create fields that use the behavior or not. This was a change FMI made from v13 to v14 because a some users wanted auto-capitalization. A very short-sighted request. They could have accomplished their desire using script triggers. But now we are all stuck with auto-capitalization and no way to get rid of it.