Page 1 of 2
Detect LOSS of 'focus' (SOLVED)
Posted: Fri Sep 12, 2014 11:59 am
by Traxgeek
Hi,
Still struggling making a working PC/Mac app work on Android... Lots and lots of little things... But this one right now is killing me...
Detecting when a user taps outside of an editable field... In fact this isn't solely related to Android (I'm dev-ing on a Mac - same 'issue').
Example, two editable fields, a scrollbar, an image, a grouped image and a label (that'll do for just now)...
Tap/click on an editable field and it gets focus -- Mac-the edit 'hilite' bar pops up, Android-the keyboard pops up. All good so far.
Now then...
Tap/click on an image, the mouseup event fires BUT the text input highlight bar (Mac) / Keyboard (Android) remains... DON'T UNDERSTAND
Tap/click on a label, the mouseup event fires BUT the text input highlight bar (Mac) / Keyboard (Android) remains... DON'T UNDERSTAND
Tap/click on a button, the mouseup event fires BUT the text input highlight bar (Mac) / Keyboard (Android) remains... DON'T UNDERSTAND
Tap/click on a scrollbar, the mouseup event fires and the text input highlight bar (Mac) / Keyboard (Android) disappears... GOOD - AS EXPECTED
Tap/click on a different editable field, the mouseup event fires and the text input highlight bar (Mac) relocates / Keyboard (Android) remains... GOOD - AS EXPECTED
Tap/click on the card itself, the mouseup event fires and the text input highlight bar (Mac) disappears / Keyboard (Android) disappears... GOOD - AS EXPECTED
I've tried playing with/trapping 'exitfield', 'focusout' and 'closefield' and passing them on... to no advantage.
Any ideas on how to rectify this please ? Apologies if this is sooooo basic... another little issue slowly driving me mad...
Thanks.
Re: Detect LOSS of 'focus'
Posted: Fri Sep 12, 2014 1:22 pm
by Simon
Hi Traxgeek,
Odd... I work with Android and I've found an image does take focus, also button, auto hilite true? Label nah.
At any rate, try it kind'a backwards
on mouseUp
focus on me
...
Simon
Re: Detect LOSS of 'focus'
Posted: Fri Sep 12, 2014 1:36 pm
by Traxgeek
I'll go do that ! Thanks Simon - sounds like a great work around.
The on mouseup... focus on me... etc would then need to go into every control (or maybe its group). I'll go check it now.
Would this not be classed as a bug ? I mean, a control either 'does' or 'does not' have focus right... ????
Generally, this isn't an issue on non-mobile but, seeing as one needs to trap the 'focus' to raise the keyboard on mobile, I'd consider this... well... an issue ? ! ??
Never mind. I'm off to try your idea - sounds great.
As an aside (there's always an aside - with me and LC they're like 'but's... !) Whilst on a desktop one can see the edit/Insert 'hilite' bar disappear on losing focus, this is not true of any hilited text one has in the control at the time... i.e. - on loss of focus, the edit/insert 'hilite' bar is removed whilst any actual hiliting is not... bizarre !
Perhaps there's a specific reason for this that I'm missing
...
Def :My loose and ready def of a desktop Mac OS / Win OS - incl laptops with fixed keyboards !!
Re: Detect LOSS of 'focus'
Posted: Fri Sep 12, 2014 1:49 pm
by Simon
Would this not be classed as a bug ? I mean, a control either 'does' or 'does not' have focus right... ????
Well just thinking of a label (not editable)... it's not really anything, a user can't do anything with it except read it.
hmmm... maybe a definition in there.
Simon
Re: Detect LOSS of 'focus'
Posted: Fri Sep 12, 2014 1:52 pm
by dave.kilroy
You can also get the field itself to do some stuff to dismiss the keyboard by using "focus on nothing":
Code: Select all
on returnInField
focus on nothing
end returnInField
Re: Detect LOSS of 'focus'
Posted: Fri Sep 12, 2014 2:46 pm
by Traxgeek
Hi,
Gotcha - both Simon and Dave ! Thanks.
Simon - typical of me to spout off with poor language ! I guess I should have clarified / been more specific with which controls - you make a valid point; I was really referring specifically to a text / input control - just seems strange behaviour; specifically for mobile (considering the need for the soft keyboard popup).
Dave - yeah, 'returninfield' needs you to hit return though. I quite often find that one simply clicks / taps from one control to another and... that's when my 'issue' arose...
The 'focus on me' message seemed to generate errors (not a valid control) but did lead me to a similar method which I'm currently working with; this one is to put 'focus on nothing' as the first code line into each of the other control's scripts that I've found (trial and error) do not create a 'closefield', 'exitfield' or 'focusout' message to be sent should a text (input) field have been the last control to have had focus...
Another aside; is there a way to force the keyboard to pop up / be displayed ?
Anyways... Thanks again both.
Re: Detect LOSS of 'focus'
Posted: Fri Sep 12, 2014 3:01 pm
by dave.kilroy
The way I usually bring up the keyboard is to send a "focus on fld "abcd"" and this should work as long as the field in question is 'focusable' (see the field's inspector) - and then "focus on nothing" (or another valid object - such as the card) to get rid of it
The 'keyboardActivated' and 'keyboardDeactivated' messages are sent to the current card if you want to move controls around to make allowances for the keyboard itself - and there is the 'mobileSetKeyboardType' command to control what kind of keyboard is shown to the user
Re: Detect LOSS of 'focus'
Posted: Fri Sep 12, 2014 4:21 pm
by Traxgeek
Thanks Dave.
I've been playing with the keyboard 'settings' (commands and messages). Really useful stuff. The bit I couldn't get my head around was the 'focus' / 'loss of focus' thing... Neat trick to simply set the focus to an editable field (so that it brings up the keyboard) and then remove it again ! The issue for me though is (being as specific as I can) I 'effectively' have one text input field and a graphic / image on the screen. (For me) navigating away from the text input control - specifically to the image control - but there are others too - (i.e. : tapping on the image control) does not remove 'focus' (the vertical text edit/input bar in the text input control)... so, because the keyboard is no longer needed, one closes (or, at least CAN close) it leaving the 'focus' in the text input control which effectively makes it difficult to re-invoke the focus / keyboard because the text control still appears to have focus - although I'm now 'playing about' with the image... Like I say, only a 'problem' with soft / mobile keyboards really... but frustrating all the same...
Just difficult for me to get my head around. For me a control either 'does' or 'does not' have focus... I guess it's just the symantec of the word 'focus' .... forgive me... I come from years of VB and C where I'd not encountered this... Still adjusting to LC... but enjoying it (kinda) !
Again, many thanks.
Re: Detect LOSS of 'focus' (SOLVED)
Posted: Fri Sep 12, 2014 8:45 pm
by dave.kilroy
Hi Traxgeek
Sounds like you are making progress (which is always good)
I was remembering that it is more than the 'focusable' property that comes into play - about 18 months ago I had an iOS app that had a scroller inside which was a field that needed to show a selected state to make everything work the way I wanted - but there was a problem in that when the stack opened that 'selectable' field would trigger the keyboard appearing (the key property was 'traversalon') - what I did in the end was to call 'unHighlighting' in the preOpenStack handler to make sure the keyboard didn't appear and then use a 'send Highlighting to me in 1 second' command in the openStack handler (I'm sure there are better ways of doing it but it worked for me at the time...)
Code: Select all
on Highlighting
set the listBehavior of field "fldGames" of card "cdWelcome" to true
set the traversalOn of field "fldGames" of card "cdWelcome" to true
set the autoHilite of field "fldGames" of card "cdWelcome" to true
end Highlighting
on unHighlighting
set the listBehavior of field "fldGames" of card "cdWelcome" to false
set the traversalOn of field "fldGames" of card "cdWelcome" to false
set the autoHilite of field "fldGames" of card "cdWelcome" to false
end unHighlighting
Perhaps you could use the 'keyboardActivated' and 'keyboardDeactivated' messages to make similar changes? Or others might suggest better methods here...
Kind regards
Dave
Re: Detect LOSS of 'focus'
Posted: Fri Sep 12, 2014 9:30 pm
by Simon
Simon wrote:
... an image does take focus,...
Argrrr... no an image cannot take focus I was wrong.
Sorry 'bout that.
Graphics can take focus!
Workaround... put a graphic with a blend of 99% over the image.
I use that all the time so that users can drop the keyboard (actually I just use a graphic in the bottom layer because I haven't needed an image yet).
Now when a user clicks the soft keyboard down while in an editable fld and can't raise it again, touch the graphic touch the fld again the keyboard come up.
Also I keep a hidden button that on openCard I set the focus to, that way the keyboard doesn't pop up until they click on an editable text fld.
Simon
Re: Detect LOSS of 'focus' (SOLVED)
Posted: Fri Sep 12, 2014 10:25 pm
by dave.kilroy
Ah yes I've heard of a hidden button being used to trap focus on startup - that would be been a better way than how I did it. And using masking graphics with blendlevels of 99 is indeed a good way of blocking interaction - but it may be that you need to set properties such as selected text of your fields directly...
Re: Detect LOSS of 'focus' (SOLVED)
Posted: Sun Sep 14, 2014 9:45 am
by Traxgeek
Hi both,
Thanks for you input.
Hidden button - simple, elegant, brilliant idea !
Masking graphic - I use that idea now - probably got the idea form yourself, Simon, on an earlier post - works really well for all my desktop work - I place a masking graphic (blend level set to 60%) so that my sub-stack dialogs pop up centre stage, immediately behind which (and on top of the main, calling, card) is a full screen blocking graphic so that users can still see the underlying / origibnal card but cannot interact with it until the 'answer' card is dealt with... Like I say, works really well...
Thank you both for you input... which has raised other questions for me so I'm off to ponder them and try a few things...
Have a great weekend guys.
Re: Detect LOSS of 'focus' (SOLVED)
Posted: Sun Sep 14, 2014 8:42 pm
by Simon
One thing to point out.
The 'normal' way of doing this on desktop is
but that doesn't work on mobile, that's why the whole btn thingy is used.
Simon
Re: Detect LOSS of 'focus' (SOLVED)
Posted: Sun Sep 14, 2014 9:38 pm
by dave.kilroy
Simon, just tried your "btn thingy" inside an openCard handler on iOS and it worked very nicely (as long as the button's traversalOn property was set) - much, much better than how I was doing it before - thanks!
Re: Detect LOSS of 'focus' (SOLVED)
Posted: Mon Sep 15, 2014 5:19 am
by Simon
Hi Dave,
Glad it worked for you, it's my blunt style.
Simon