Detection of Keyboard Closing

[Michael Doub]

I am happy to report that all three approached work.  The keyboard stays hidden until the field is touched.  Enter some data with the keyboard, switch focus to another field, touch the initial field, focus switch and keyboard comes back up.   All seems normal.   

However I think I found a bug.   If you DO NOT enter any data just close the keyboard, switch focus to another field and then touch the initial field, focus will not move back to the field touched therefore no keyboard will appear.  I am using 5.5rc1

So there is still no answer  my original question of knowing when the keyboard is closed.  I see now that you might be able to use the focusOut message but the keyboard can be closed and the field can still have focus.   In my experiments, I was fortunate that i had another field that could acquire focus and pull it away from the first field.  Closing the keyboard does not remove focus.

-= Mike



On Mar 14, 2012, at 6:01 PM, Peter M. Brigham, MD wrote:

> The other way, which I have used for some time, is to group the field (either in a group by itself, or including all the fields you don't want to automatically get focused) then set the group's traversalOn to false.
> 
> -- Peter
> 
> Peter M. Brigham
> pmbrig at gmail.com
> http://home.comcast.net/~pmbrig
> 
> On Mar 14, 2012, at 4:03 PM, J. Landman Gay wrote:
> 
>> On 3/14/12 2:09 PM, Michael Doub wrote:
>>> Is there a way to detect that the user has closed the keyboard on
>>> Android?
>>> 
>>> Maybe someone can point out an appropriate technique to solve my
>>> problem.  I have a card with one editable field on it.  When I go to
>>> that card currently the focus immediately go to that field and the
>>> keyboard pops up.   I would like the field to remain editable, but
>>> only if it is selected by the user.  I would like to be notified upon
>>> completion.
>> 
>> It's an ancient problem that dates back to the origins of the engine. The first object with traversalOn will get the focus. On Windows, where buttons can be focused, the solution is to set a button to a lower layer than the first field. On Mac, and apparently mobile (I haven't checked,) that doesn't work.
>> 
>> One workaround is to add a short handler that removes the focus and send it from a preOpenCard. It doesn't trigger right if you just add "focus on nothing" to a pre- or openCard handler.
>> 
>> on preOpenCard
>> send "noSelect" to me in 1
>> end preOpenCard
>> 
>> on noSelect
>> focus on nothing
>> end noSelect
>> 
>> I haven't tried this on mobile yet, but that's how I do it in desktop apps. On mobile the keyboard might pop up and disappear if the timing isn't right. Let us know.
>> 
>> Another way to handle it is to set the field's traversalOn to false in preOpenCard and then set it back to true on openCard. I've had mixed results with that method, but you can try it:
>> 
>> on preOpenCard
>>  set the traversalOn of fld 1 to false
>> end preOpenCard
>> 
>> on openCard
>>  set the traversalOn of fld 1 to true
>> end openCard
>> 
>> -- 
>> Jacqueline Landman Gay         |     jacque at hyperactivesw.com
>> HyperActive Software           |     http://www.hyperactivesw.com
>> 
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode