widget.newEditField

Solar2D Widgets
#1

Hi Business Apps Guys,

Seems we are all running around trying to solve the problems with edit fields under Corona. So lets get going :slight_smile:

This is a new thread after Renato wisely proposed we all merge our attempts to get our best workable solution - please contribute with ideas, proposals, code snippets etc.

Current contributions :

Renato RGB - https://bitbucket.org/redbeach/

Mine - https://github.com/atanasster/framework-widget/blob/master/widgetLibrary/widget_editfield.lua

Let me post some of the current features in my check-in. Renato please also update here the features from your so we can start the discussion since we went at it a little differently (my implementation is based on the newSearchField widget).

– ability to hide the field when not in focus - this allows us to have scenes/graphics on top of edit fields

– ability to move/group the field with other graphical objects

– uses a 3-frame slice for theming

– ability to place icons or buttons around the field

– ability to place a lebel in front of the field

– ability to make the field non-editable for usage like a combo box with a list for selection when clicked instead of showing the textfield

– ability to specify a “placeholder” (hint) when the field is empty

– Ability to have a “cancel” button to clear the field

– Reverts back to the newSearchField theme if you do not have a editField theme available in your app

– limit the number of chars

– onSubmit event when the user leaves the field or when pressed Done button

Here is an example usage

local labelField = widget.newEditField

    {

        

        x = display.contentCenterX,

        y = 130,

        width = 300,

        label = “Field with Label:”,

        labelColor =
[sharedmedia=core:attachments:1175]labelColor
,

        placeholder = “Enter a city…”,

        maxChars = 10,

        editFont = font,

        editFontSize = fontSize,

        editFontColor = fontColor,

        onSubmit = onSubmit,

        widgets = { 

            {kind = “icon”, defaultFile = “images/coffee_cup.png”, align=“left”},

            {defaultFile = “images/filling.png”, align=“right”, onRelease = onSelectCoffee},

            {style = “clear”, defaultFile = “images/clear.png”}

        }

    }

Here is a screenshot of a form with edit fields 

tenniscount2.png

#2

It has been great working with Atanas testing his widget.newEditField. So much progress in such little time. Renato’s feature set sounds great too. Merging these going forward will be great! Thanks for all the efforts. 

#3

Kerem, your help has been invaluable and your passion contagious :slight_smile:

Let me contribute with a couple of items on the todo list that have been on my mind:

  • ability to have a frame for required/validated fields (so the user has a visual cue that he needs to enter values in those fields)

  • ability to move the underlying group automatically up if the field is too low when the field receives focus - I believe Renato has already implemented this?

  • a 9 slice frame would be desirable for most control over the size of the field.

  • try to fix the alignment issues we seem to both have with Renato. I have a couple parameters that you can set in the newEditField to play around - and see what works best on the different devices and resolutions to align the fake label and the textfield:

textFieldYOffset

textFieldXOffset 

fakeLabelShiftY 

fakeLabelShiftX

  • a mode where the textfield/newText are swapped only when a scene change occurs instead of the current way every time the focus is lost. This seems would look more “native”

  • scaling, aligning

#4

I’m coming to this discussion late, so perhaps you guys are already ahead of me, but it seems that all of this needs to be implemented on top of a scrollView so that the whole form moves as a unit and we can move the form/page up to adjust for the keyboard…is that the plan or is that too big of a bite to take??

#5

Just a heads up on placeholders.   Apparently native.newTextField() has a .placeholder attribute that does what you want it to do.  It’s on iOS and OS-X only.  But I was trying to implement my own placeholder and ran into problems, so if you choose to implement your own, don’t call it .placeholder or it will conflict with the native one and the native one wins.

If you’re building something like an iOS settings screen, that’s done in a tableView. But most other apps, the fields are not hand-scrollable so I would just insert them into a display.newGroup() perhaps called “formGroup” and then transition it so that the currently selected field is on screen.

Rob

#6

Rob…the docs say (as of about a week ago) that you CANNOT insert native objects into groups or move them as a unit…has that changed??

Thanks for the tip on .placeholder…that needs to be added to the docs as well…

Your point about “hand scrollable” is lost on me…whether or not “fields” are hand-scrollable, the other display objects on-screen around them certainly are, and you need it all to move as a unit…I’m probably mis-understanding something about what you are saying… please clarify if so.

#7

No you cannot insert native objects into display groups.  This has not changed and is not going to.  However, the work being discussed here is based on a tutorial we did a couple of weeks ago as well as the native.newSearchBox() API that we never surfaced.  In this case, we draw a native.newTextField() with no background over top of a display object.  Its that display object that gets put in the display group.   In my example, I used a runtime event listener to keep the native and display fields in sync with each other.

Rob

#8

In addition to the existing amazing achievements and the to-do lists, may I also suggest the following : 

  • Numerical text entry mode - Only numbers and one decimal point allowed.
  • Currency entry mode… Almost same as above but with a prefix currency symbol of choice (ie $, euro etc) attached to display text only. Value entered should be retained as a proper number without the currency symbol attached.
  • Keyboard mode - It is possible to control which keyboard is triggered when we enter the native.inputField. We could bring this back into the widget.newEditField options

Thanks for all the hard work. Happy holidays to you all. 

#9

Dg, you are certainly not late - at least my code is early beta version and still trying out many thing. Kerem - excellent list of additional features. For t Validation, it would greatly help if we have a beforeedit event to control what characters are allowed without having a flickering (we could return true/false) and let know if a typed char should be allowed. For the keyboard type - do you have in mind the basic inputType parameter that we already have or to have completely custom keyboards that we pop up? Rob - I used the same name placeholder as the newTextField for consistency, but internally its only used to display text in the fake label when not in focus. I dont think it conflicts with the newTextField placeholder. However a better name would be hint, right? Thanks Atanas

#10

Rob - do you know of a way to make newTextField invisible instead of moving it off screen?

#11

Sorry for not being clear. I was trying to say the Return key on the keyboard being controllable in addition to inputType. Something like a 

    keyboardType = “search”, – in your widget paramaneter

which goes into the following in the widget : 

    field.textField:setReturnKey(opt.keyboardType)  

Allowable values are documented at : http://docs.coronalabs.com/api/type/TextField/setReturnKey.html

#12

Have you tried setting isVisible or .alpha = 0 on it?  (I don’t know if it works or not)

If you move it off screen, you won’t be able to move the cursor in the middle of the field.  This is the reason why I went the route I did (as well as why Alex did the same with his search field.)

#13

.alpha = 0 worked for me in my Search Bar as in IOS Mail App sample. 

#14

IsVisible is not available unfortunately, that’s why I asked. I tried alpha = 0, but you can still select the field when a scene is on top of it Rob, can you explain about the cursor in the middle? Can you give a spin to my editField when you have some time -you just need the part of widgetext.lua that creates somewhere in your project : local function newEditField( options ) local theme = _getTheme( “editField”, options ); if theme == nil then --if the current theme does not have a editfield, revert to searchfield theme = _getTheme( “searchField”, options ) end; local _editField = require( “widgets.widget_editfield” ) return _editField.new( options, theme ) end widget.newEditField = newEditField;

#15

Hmm, why is it when I use the forums to post from my IPad all the new lines are taken out?

#16

Kerem, returnKey is already an option in the constructor

#17

When you use a native text field, the user can touch in the middle of the string and edit from there.  If you move the native.newTextField() off screen and just have it constantly update a display.newText(), then you would have no way of allowing people to touch the display.newText() and know where in the string they are touching.  The display.newText() is a rendered graphic and without knowing the font metrics you would have no way of knowing what character they are trying to select.   Then you have the issue of building in support for Select/Select All/Copy/Cut/Paste features that you get with the native.newTextField.

Your best bet is to move the native.newTextField off screen and put a touch handler on the box that moves the native.newTextField() back on screen if you want to go that route.

Rob

#18

Ah, ok.

Currently, the first touch activates the field and a second touch can be used to display the magnifier glass and select text in the middle of the textfield. Its not like the real thing, but then we do need editFields, so I would go with a hack as long as it gives the feature.

Here is what I was thinking would give the most “native” feel - its to move the textFields offscreen only when the scenes are changed - if a scene with edit fields receives an exitScene, it moves all its textFields offscreen and replaces them with the fake labels. 

When a scene with edit fields receives an enterScene, it moves back all the text fields that are on it onscreen

This way the user will have a “native” experience with the active scene (will not have to use one extra touch to activate the fields) and we can still have a workable solution to display overlays and scenes on top of other scenes. 

I have started subclassing storyboard to maintain internally a list of editFields on each scene, and to automatically hide/show the textfields and will upload it later.

I don’t really get your suggestion with the touch handler on the label and then how to send a touch event to the native.textField that is offscreen?

Anyone any other ideas?

Atanas

#19

Aaaah, now I see you what you were saying about offscreen and update the label from the textField. But thats not how newEditField is implemented currently as it would be really unnatural feeling - currently the textFields are moved on-screen as soon as the user touches the fake label and the focus is set to the textField so the keyboard shows right away. When the textField loses focus, its immediately removed offscreen and replaced by the label.

So I guess the current implementation is the same as your suggestion. The only drawback is that the magnifier glass shows only on a second tap by the user.

I thought your suggestion was to send touch events to the TextField to set the magnifier glass at a specific position from the first touch.

#20

I totally missed that. Thank you very much! One more point for the home team!!!  :slight_smile: