Widget for text input...

Solar2D Widgets
#81

How about a very good tutorial on off-screen handled native textField with all the event bells & whistles then? Something we can all learn from and use as a best practice in this challenging field.

The last tutorial on this topic posted in Feb 2012 is now offline with a pointer to the API documents as being replacements… There is a video tutorial on native textFields and keyboard use but that one is not using the off-screen handling that has been often recommended. If you can’t write a widget that will do this properly and in a well managed way at least help your community with a great tutorial that can be used in real life. 

Particularly I think you need to make sure to demonstrate 

  1. Off screen native textField placement
  2. textField visually embedded into scrollViews & tableViews
  3. Handling auto-correct, spelling etc.
  4. Copy / Paste
  5. Pre-loading a textField with data that user can edit
  6. Limiting numerical text entry to numbers and decimal point etc
  7. How to use different keyboard types offered on each platform
  8. Formatting text-entry fields to serve other purposes (ie Search Box)
  9. IOS & Android Compatibility

Voters have spoken. It is now up to Corona Labs to show whether the feature requests and votes given matter or not. Thank you. 

#82

Great @atanas.

I just created a public repository and upload our rb-display lib that includes our newTextField “widget” version.

In few words, it basically substitutes the native textField with a newText together a newRect (or newRoundedRect) when the native textField is not in use (focus)).

Some features already implemented:

– . Keyboard automatically hides when touching outside the textField

– . Auto-translate the screen to avoid the inputField to be hidden by the keyboard device

– . Obey to group behaviors, specially useful for use together with storyboard

Improvements still needed:

– . Adjust font differences between the placeholder text and the text inside the native field, specially on Android devices

– . Support to native textBox 

The link to repository is https://bitbucket.org/redbeach/

#83

Very cool Renato, I have checked in mine at https://github.com/atanasster/framework-widget/blob/master/widgetLibrary/widget_editfield.lua

I will start a new thread to discuss the features that we all need and a way to merge all the copies

#84

So nice to see the collaboration. Thank you very much for all this. 

#85

Great idea atanas. Let’s centralize the collaboration in a specific thread.

Just did a quick look thru your widget and it has some very interesting features. 

#86

Rob, thank you very much for the tutorial posted just now. Referencing for others : 

http://www.coronalabs.com/blog/2013/12/03/tutorial-customizing-text-input/

After a quick glance, I think its a great start and there are certainly some great takeaways there (ie synch fields etc). I will review it tonight in detail and apply what I learn to my project and the little searchBox sample.

If you were to write a follow-on piece it would be great if you could cover the following : 

  1. Off screen native textField placement. This method is often referred to as a way to handle native.textField issues but there is no good sample/tutorial.
  2. Handling auto-correct, spelling etc. Disabling them so they don’t interfere etc. 
  3. IOS & Android differences, intricacies. 

Thanks once again. 

#87

#1 works well for certain cases where you just need to type and backspace. But if you want to touch the middle of the string and edit it, the native.newTextField has to be on screen for that case.  One of the problems which lead us to say just hide it off screen was because hiding the background didn’t seem to work in some cases but that’s been addressed.  

#2 is going to require us adding features to support turning on and off autocorrect and other features.  I’m pretty sure there are entries in the feedback site for this and the more votes the better.

#3 Other than the issue with the hardware back button turning into a keyboard dismiss button that doesn’t generate a catchable event in Android, there shouldn’t be too much difference wise between the platforms at this point.

Rob

#88

Got it. Read it again and now I see what you did there! You actually wrote an extension to the widget library. So why can’t this be included in the next update to the widget library and get formal support from then on? I think it’s a great start and as you also point out above it perhaps meets 90% of the needs. So why not make it a formal part of the widget library? Just a thought… Thanks once again.

#89

Thanks Rob,

Very timely help from you - I am in the process of implementing edit fields very similar to your approach, and was missing some of your clues. Additionally will need to support a text label to the left or an icon (like a phone for phone entries, person for names etc), theming and an incremental search popup/calendar for easier data entry.

Have you given thought on having a newText that alternates with the editfield - when you touch the newText, it gets replaced by the native text field and then when it loses focus we swap them back and the edit field is destroyed, yet the data is still displayed - as an alternative to simply destroying the edit fields every time we exit the scene? The problem I have is with popups over textfield - for example an incremental search popup that should show on top of the current screen.

#90

Hi Rob,

Just a question - why not use widget._new( options ) instead of newGroup() since you are creating it as a widget (and no need to add the finalize notifier)?

Thanks again

  Atanas

#91

Part of writing a tutorial is to be somewhat succinct.  If I had to write about all of the underling pieces to make it something engineering could include in, the tutorial may have been twice as long.  I firmly believe that many of you can look at the widget code and understand it without an in-depth explanation, the blog post has to also service those who want a shorter, simpler option as well. 

I did model it after widgets (using the same basic option handling process), but I didn’t fully follow the coding styles and such to try and keep it as simple as I could (I didn’t use _'s for private variables for example as that makes it harder to follow). 

In addition to the keep it simple needs, there are also time constraints that limit how much time I can put into this (I have deadlines for publishing…).   For this to become a real widget, it would have to support using themes, support skinning options that would at least allow you to pass in a graphical background, and probably even a 9-slice option like widget.newButton.   It would need to handle more transition support.  Right now the sync function only handles x and y movement.  It needs to support a host of other things like visibility.

So maybe some day, this can be the seed for a formal widget, and perhaps it will inspire one of you to take it as the basis and make it great.

Rob

#92

Well, it remains one of the most requested features and you sure have shown the way forward. Now, I hope Walter, David and all the other decision makers at Corona Labs can take it to the next step and add a formal text entry widget into the lineup. 

Meanwhile we have your excellent tutorial to learn from. Thank you. 

#93

Thanks Rob, You are doing a fantastic job, I hadnt considered transitions, also your android scaling method is something I didnt see anywhere else The newSearchField is implementing a 3 slice theming, but you are right that a 9-slice would be better. I will guys let you know also if alternating with a display.newText has any promise. Thanks again Atanas

#94

Rob, this is looking great! I was able to extend it with ease (as you suggested) to include options to manage the keyboard type shown along with the input prompt… Also added an option to bring the keyboard up automatically without having to tap on it first. This is quite common in situations where there is only one inputField displayed.

Additions to code hilighted below : 

    opt.inputType = customOptions.inputType or “default”

opt.keyboardType = customOptions.keyboardType or “done”

opt.autoPopKeyboard = customOptions.autoPopKeyboard or false

    opt.font = customOptions.font or native.systemFont

    field.textField.inputType = opt.inputType

field.textField:setReturnKey(opt.keyboardType)

    field.textField.text = opt.text

if opt.autoPopKeyboard then

native.setKeyboardFocus( field.textField )

end

#95

Rob, 

I wanted to implement the behavior where the input field is presented with an initial text which disappears when you first tap on the field. I managed to do this with ease in my main.lua using the following approach… Simple check and clear text in the began phase in my listener function.

local eraseInitText = true if event.phase == "began" then -- check if we are supposed to clear the initial text supplied to the widget if eraseInitText then event.target.text = "" eraseInitText = false end

This is all fine and it works but ideally I would like to push this capability into the widget code in widget.newTextField.lua and turn on/off through another opt.eraseInitText type variable. 

How can this be accomplished? Is it possible to have some of the listener code implemented on the widget code side rather than main.lua side?

Thanks much

#96

Hi Ksan,

Isn’t newTtextField.placeholder doing what you need ? Or you need some custom functionality?

Cheers

  Atanas

#97

The placeholder is fine. I just want it to disappear (optionally) when I tap on my field on display. Similar to what happens when you tap on Search in IOS mail for example. The code above accomplishes what I need so all is nice. It would be nicer if I can put this in Rob’s code though rather than keep it in the listener outside the widget code hence my question. 

#98

Aaaah got it:)

You can implement a listener in the widget and inside of it do the logic. Inside this widget implemented listener you would also show/hide the keyboard. Then if the user has supplied a listener function call it at the end

#99

Yup. Thats exactly what I need to figure out. Thanks for your guidance. 

#100

They have it in searchEditField - let me know if you need a code extract