iOS Keyboard input question
livfoss at mac.com
Mon Oct 1 09:14:16 CDT 2012
I'm working on an iOS app where keyboard input is allowed for a set of fields shown on the screen of the device: some are still visible when the keyboard comes up, i.e. not hidden by the keyboard - this is by design. These single-line fields are locked, with TraversalOn true, since in iOS you can't type directly into a field but have to do it via the system keyboard.
What the user does is to touch a field which he/she wants to update. This triggers a data entry sequence starting with a 'focusIn' handler which brings up the keyboard and a particular screen area (a pseudo-field really) to type into, as per the current LC iOS documentation. After input, the user touches 'Done' and this triggers a 'inputEndEditing' handler which allows my script to look at the text which has been input, verify it, put it away in the original field which started the sequence, and remove the keyboard by making it invisible. So far so good.
However, what I find a typical user wants to do is to bypass the 'Done' key after doing the initial input and instead simply touch another field that needs updating and is not obscured by the keyboard. This, I find, does fire 'focusIn', but the keyboard display goes wrong. What I want to happen is for my 'inputEndEditing' actions to take place normally for the initial field, including (momentary) closing of the keyboard, followed immediately by the 'normal' action for the second field to be touched. (I need the keyboard to be replaced between actions since sometimes I want a text keyboard and sometimes a numeric one.)
I have tried detecting when the second touch takes place and then sending or calling 'inputEndEditing' at that point, but I can't get this to work. Possibly this is because the whole script is taking place within a behavior which means I don't know where the 'send' should go to retain local variables.
I am trying different solutions and may crack it on my own, but I'd be grateful for any advice about how anyone else has tackled this.
More information about the use-livecode