iOS Keyboard input question

[J. Landman Gay]

On 10/1/12 9:14 AM, Graham Samuel wrote:
> 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 thought the inputEndEditing message was sent whenever the input field 
loses focus. Seems like you should be getting that message right before 
the second field triggers the focusIn message. Is that not happening?

You could insert a temporary "put" statement at the beginning of the 
handler to see if it is triggering, and watch for it in Console. Maybe 
something is aborting the handler before it finishes executing.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com