How do I use Native Text Controls on Mobile
This lesson describes how to interact with the native UITextField class from within your LiveCode application.
Screen captures and sample code are provided.
You can download the sample stack from this url: https://tinyurl.com/y8lyj2x4
This lesson shows you how to interact with a native text control within your LiveCode application and demonstrates some of the features that are available. You should review the user guide in order to get updates on the features covered here.
Creating a Test Interface
The interface shown in this step provides a number of option menus that allow you to set properties that control how you interact with the native text field. You can control font size, border style, auto correction type, keyboard type, content type, text color, text align, auto capitalization, keyboard style, return key type and receive the editing, text changed and return key messages. This list is only a subset of the native text field control features that are available in LiveCode.
The option menus do not contain any LiveCode script and are processed purely on the content of their names and labels. A generic message handler probes the content of these values for each option menu and applies the value using the command mobileControlSet.
Setting up the Button Code
The stack in this lesson has three buttons: The Reset Text Changed button, the Create button and the Delete button. Each of these buttons executes a small script. These scripts are listed in this step.
The Reset Text Changed button changes label "Text Changed: true" to "Text Changed: false"
on mouseUp put "Text Changed: false" into field "textChanged" end mouseUp
The Create button creates an instance of a text field.
on mouseUp inputCreate end mouseUp
The Delete button deletes an instance of a text field.
on mouseUp inputDelete end mouseUp
Setting up the Stack Code
The card stack contains a number of message handlers that are responsible for a number of control aspects within the application. The comments in the following message event handler scripts provide details of what each script does.
on closeCard # Handle the close card event inputDelete end closeCard on inputCreate # Handle the input creation event if the environment is "mobile" then if "testinput" is among the lines of mobileControls() then # ensure that only one native text input is open inputDelete end if mobileControlCreate "input", "testinput" # set the native text input field to the size and position of the graphic input rectangle mobileControlSet "testinput", "rect", the rect of graphic "InputRect" # make the native text input field visible mobileControlSet "testinput", "visible", true # focus on the native text input field mobileControlDo "testinput", "focus", true # make sure the selected option menu options are applied to the native text input updateFieldProps end if end inputCreate on inputDelete if the environment is "mobile" then # delete the native text input mobileControlDelete "testinput" end if end inputDelete on inputFocus # set the focus to the native text input mobileControlDo "testinput", "focus" end inputFocus on inputBeginEditing # handle the inputBeingEdited message # this updates a label field on the interface put "Editing: true" into field "editing" end inputBeginEditing on inputEndEditing # handle the inputEndEdited message # this updates a label field on the interface put "Editing: false" into field "editing" end inputEndEditing on inputTextChanged # handle the inputTextChanged message # this updates a label field on the interface put "Text Changed: true" into field "textChanged" end inputTextChanged on inputReturnKey # handle the inputReturnKey message # this raises a dialog box, indicating that the return key was pressed # and focus was removed from the text field answer "The return key was pressed" with "Okay" end inputReturnKey on mouseUp # handle any mouseUp here that is not handled explicitly by a control if word 1 of the name of the target is "button" then if the platform is "android" then // Show the options // On other platforms the options are shown automatically local tTarget, tOptions put the long name of the target into tTarget put the cOptions of tTarget into tOptions mobilePick tOptions put the result into tResult if tResult is not "cancel" then set the label of tTarget to line tResult of tOptions end if end if updateFieldProps end if end mouseUp
Updating the Properties
As discussed earlier in this lesson, the option menu items do not have LiveCode associated with them. Rather, they are processed using a generic message handler that uses the name and the label of the option menus to set up the respective control that has been changed. updateFieldProps is stored on the stack script and implements this generic process.
on updateFieldProps local tX # ensure that we are handling messages from our native text input if "testinput" is not among the lines of mobileControls() then exit updateFieldProps end if # loop through each control on the card repeat with tX = 1 to the number of controls # if the control name does not start with "property" then go to the next item if word 1 of the short name of control tX is not "property" then next repeat end if # set the native control property using the value of the current card control mobileControlSet "testinput", word 2 of the short name of control tX, the label of control tX end repeat end updateFieldProps
Note: Using a generic process to apply any option menu selection allows you as a developer to add or remove option menus, knowing that any further LiveCode changes are minimal or not needed at all.
Editing Example 1
Once you raise your application on the iOS device of choice, you should be presented with the following or similar display. You have to select the button Create before you can start entering text. Once text has been entered (see next example), you should see how the label content of Text Changed and Editing changes. You can reset the Text Changed label by selecting the Reset Text Changed button. Selecting the option menus and altering their content should have an immediate impact on the content that is displayed in the text field.
Editing Example 2
You can enter text by selecting the text input area. This raises the keyboard you specified under the Keyboard Style option menu. Type in the text as required and complete editing with the return key.
Using the Native Text Control
Once the native text control is created it has all the behavior of a iOS field.
You can touch and hold on the field to show a magnified view or touch and release to show editing options.
Hello, very interesting !
Is it possible to find this stack already done ?
I have uploaded the sample stack to this lesson.
the autoCapitalization does not work. The name for this text input property is autoCapitalizationType and not just autoCapitalization.
So to get autoCapitalization working you have to rename the btn "property autoCapitalization" to "property autoCapitalizationType"
Btw: the dictionary also lists the wrong property name.
thank you very much for your comment. The test stack has been updated and the dictionary entry fixed for the next release.
Thanks for this - very helpful, however ... I downloaded the sample stack and when I want to open it, Livecode gives an error message: "there was a problem opening the stack: file is not a stack". Is the file to download corrupted in some way?
no, the stack is not corrupted. As of release LiveCode 5.5.0, the file format is changing to accommodate some of the new features we added.
The features in the sample stack do not take advantage of the features that require the new format, so I uploaded the stack again in the format that is supported with older versions of LiveCode.
You should be able to download and run the stack now.
Is there a way to format just a part of the text inside.the native control input?
For example: first line bold, second line italic...
I don't believe there is, all styling applies to the whole control.
The properties you can set on native controls can be found in the Dictionary entry for the mobileControlSet command.
Perhaps an idea to make it clear in the lesson heading this is designed for *iOS* mobile devices?
Thanks for bringing that to our attention, I have updated the attached stack so that it work in Android and iOS. It is only the mouseUp handler that needed updated as on Android Option Menu controls do not work automatically as they do on iOS and desktop.
I have an Andoird 7.0 phone and an Android 10 TVbox.
The mobile text input behaves differently on the 2 platforms:
On the cell phone, clicking on the field opens a dedicated system input window, with keyboard and lot of room for entering text.
On the Android box, clicking on the field behaves like on a iPhone: the keyboard emerges but the top part of the screen remain the one of the standalone, eventually sliding up for showing the filed above the keyboard.
Is is caused by the Android version? The type of android hardware? O some LC setting I don't know about?
What is the model of the Android 7 device? Have you installed any custom keyboard app? The expected behaviour is the one of the TV Box.
@Panos I have two of them, behaving in the same way (dedicated text input system window:
- Galaxy A5 (2016) Android 7.0
- Huaway P8 lite 2017
I will emailed you a screenshot
I will email you
Thanks for the screenshots. Do you see the same when the device is in portrait orientation?
In effect, no.
But I am working on an horizontal only standalone.
Anything i can do?
What you see is the expected behavior on landscape orientation. I just tested with a native (non-LiveCode) app - I tried with Gmail - and I see the same behavior on landscape mode. Can you please confirm?
Not really. On the Android 7 Galaxy A5, using landscape (1= dedicated OS text input window, 2= windows doesn't mostly change from before touching the input field:
on gmail, composing a new email = 2
on Contact, changing the name of a contact = 2
on Promemoria (I think "memorandum" in English)= 2 (but it is hard to say: there are icons, multiple fields visible, but the look is the 1
What I believe is that even the dedicated text input window can be personalised and probably there is a programmer choice. Can it be?
Thank you for the follow up.
Heh, I just realised what you mean by "dedicated system window". In your screenshot, I saw the "FINE" button on the right, and I thought it was part of your app's UI. I did not realize that "FINE" is the equivalent of "DONE" or "END" in Italian :)
Anyway, I did some research and had a look at the engine source code and it looks like we already do what is suggested in this case, to prevent showing a "dedicated system window" (https://stackoverflow.com/questions/4336762/disabling-the-fullscreen-editing-view-for-soft-keyboard-input-in-landscape)
So this needs to be investigated further. I'll file a bug report to make sure this is not lost in the lesson's comments.
Can't find the bug report, to check if it has been solved. Can you post a link?
Hello Roberto. You couldn't find it because I had forgotten to submit it :) Did it just now - here it is:
I am still struggling on filtering input on mobile field, like you do on desktop. Like:
On KeyDown pKeyName
if pKeyName is in "+0123456789" then
What is the best solution?
I _think_ the KeyDown/KeyUp msgs are not sent on mobile. But the rawKeyDown/rawKeyUp ones are sent.
Just to add that the rawKeyDown/rawKeyUp msg are sent to the LC field object.
If you are using a mobile native text input field, you could try using the inputTextChanged msg, where you could check the last entered character and delete it if it is in "+0123456789"
This is what I do on iOS.
On Android, there is a problem (I reopened the bug 23258) because the insertion point goes to the beginning of the mobile control field.
Thanks for the reminder. I have filed a separate report about this bug: https://quality.livecode.com/show_bug.cgi?id=24055