Page 1 of 1
Filter mobile control input
Posted: Mon Apr 13, 2026 12:07 pm
by trevix
Hello.
While filtering on regular input field is easy:
Code: Select all
on keyDown pKeyName
if pKeyName is not in "0123456789abcdefghijklmnopqrstuvwxyz.-'èéòàù " OR the number of chars of the target > 12 then
beep
else
pass keyDown
end if
end keyDown
doing the same thing on a mobile control on iOS and Android, is cumbersome for me.
Using the "inputTextChanged" command seems to be the way to go but I cannot figure out.
Thanks for any help.
Trevix
Re: Filter mobile control input
Posted: Mon Apr 13, 2026 3:14 pm
by dunbarx
Trevix.
I do not work in mobile.
But is the issue that the "keyDown" message deals with the very character that invoked it, but the "inputTextChanged" message fires only with when the entire contents of a control changes, and does not specifically "know" which char was the culprit?
If so, at least I get it, and maybe there is a way forward.
But the "KeyDown" message is supported in mobile, why does it not work for you? Did I mention I do not do mobile?
Craig
Re: Filter mobile control input
Posted: Tue Apr 14, 2026 11:17 am
by trevix
Apparently, keydown works on mobile app only with regular LC fields.
If you to a mobilecontrolcreate input field, no chars reach the keydown.
What wonders me is that text input filtering in an App is in my opinion is a fundamental need, but I could not find any reference for mobile controls.
Think of items delimiters and what a mess can result on handling the input, if the user enter special chars.
Re: Filter mobile control input
Posted: Tue Apr 14, 2026 11:38 am
by richmond62
The ability to produce mobile apps with LC has always been an ability tacked on to LC . . .
It would seem intuitive that ALL fields should pick up keyDown signals.
Re: Filter mobile control input
Posted: Tue Apr 14, 2026 12:09 pm
by bn
Hi Trevix,
Using the "inputTextChanged" command seems to be the way to go but I cannot figure out.
Maybe you could react to the "inputTextChanged" message to trigger a handler with
put mobileControlGet(tControlID, "text") into myText
then do your filtering on myText
and then mobileControlSet tControl, "text, myText
This is pseudocode and untested but maybe a way to solve your problem.
Kind regards
Bernd
Re: Filter mobile control input
Posted: Tue Apr 14, 2026 4:48 pm
by dunbarx
Bernd.
If Trevix is only interested in being able to trap a message and call a handler, I would say your suggestion is valid. But his original post seems to indicate that the parameter "pKeyName" is required for each separate filter operation to work properly.
I could be wrong.
Trevix?
Craig
Re: Filter mobile control input
Posted: Thu Apr 16, 2026 2:58 pm
by trevix
dunbarx wrote: ↑Tue Apr 14, 2026 4:48 pm
Bernd.
If Trevix is only interested in being able to trap a message and call a handler, I would say your suggestion is valid. But his original post seems to indicate that the parameter "pKeyName" is required for each separate filter operation to work properly.
I could be wrong.
Trevix?
Craig
You stand correct.
Beside, mobileControlSet tControl, "text, myText, on Android put the insertion point at the beginning of the mobile field...and this for every key press!
The only filtering I could do is like @Bernd suggested.
Code: Select all
on inputTextChanged
-- -- # handle the inputTextChanged message
if the platform = "iphone" then --on android put the cursor at the beginning,no matter what
put mobileControlGet(sControlID, "text") into tText
put word 1 to -1 of tText into tText ----delete spaces before and after
if the number of chars of tText > 12 then
put char 1 to 12 of tText into tText
mobileControlSet sControlID, "text", tText
Play (gPrefTF["AllPath"]["SoundsPath"] & "bozo1.wav")
end if
end if
end inputTextChanged
But this is a long way from "filtering".
Yes, I could check for every single char if is correct, but only on iOS.
About Android, I filed a long time ago a bug report (BUG 24055 confirmed by Panos on 2022(!!!), but it wasn't solved.
Somebody said, if I remember well, that the problem was on Android not LC. But I doubt it.