Widget for text input...

Solar2D Widgets
#1

@Chevol articulated this need perfectly here :

http://feedback.coronalabs.com/forums/188732-corona-sdk-feature-requests-feedback/suggestions/3577682-widgets-to-replace-native-textbox-and-textfield#comments

He said…

It is almost impossible to use native.newtextbox and native.newtextfield because they are not part of the OpenGL canvas and always have to appear on top of everything. Not responding to display group movement really makes you have to hack together solutions to make it all work. I think they finally need to be made into widgets so they will act like other display objects in Corona.

This feature suggestion was posted back in January 2013… Almost a year and 296 votes later, can we please have this feature implemented?

With all due respect, whenever someone asks for a new feature, Rob or Brent jumps in with a request that they submit a feature request… From then on its like a black hole. I don’t know if any feature decision is made at CL based on what the user base is asking for…

This one is simply one of the highest voted feature request. it will certainly help raise Corona SDK’s profile as not only for business apps but also for games. After all text input is as foundational as it gets when it comes to features…
 

Edit : Another request… Make textfield input work on Windows Simulator for Android as posted at http://feedback.coronalabs.com/forums/188732-corona-sdk-feature-requests-feedback/suggestions/3824956-make-textfield-input-work-on-windows-simulator-for has another 167 votes… Obviously if we have a text entry widget this request will be fulfilled as well.

Would be great to hear that this will be done and soon. Please show us that all those feature suggestions and votes are not for nothing.

Thank you very much

#2

Added my 3 votes :slight_smile:

#3

Thank you for your support! Now 272!!!

And welcome on board by the way. Great 1st post. Thanks.

#4

Thanks for the welcome - using it for business type apps and battling with the usual suspects - buttons, data entry controls , layout system

#5

Bump!

#6

Added my 3 votes guys…this is a MASSIVE show stopper regarding business apps.

User input is as basic as things get…crack this and people / businesses will start taking Corona very seriously! 

#7

Thanks for all the support. I think this feature request needed some visibility so I’m happy we are getting a focus and more votes… Now it is literally sitting at the top of the list as the most requested feature.

Lets see if Corona Labs actually do care about what we put into the Feature Request system and what we vote for… 

#8

added 3 votes. Im currently trying to build a business app and the issues with native text fields are about to push me away from using Corona. I really like using Corona but this is such a basic thing that should work without having so many work arounds

#9

Thanks to all your support and perhaps the newfound visibility thanks to this thread, the two feature requests listed above are now sitting comfortably at 284 and 158 votes respectively. Still no response from Corona Labs on whether they might consider to do something about this most requested feature / capability which also happens to be one of the most basic and foundational needs one has in any development tool. How many more votes and wait will it take? 

#10

We have actually responded to this question on many occasions and the answer has not changed. It’s one nobody is happy about including ourselves.

Working with text is an incredibly difficult task.  For starters, you have to support every language on the planet. You have to support not only left-to-right text, but right-to-left as well, emojies, various glyphs, shift states, control states, etc.  Apple and Google have spent years with dozens of engineers to build in the keyboard support that they have.  We can’t just magically recreate that.

Believe me, we would love to do this this, but its not something we can reasonably tackle.

Rob

List of open Widget 2.0 bugs & promised features...
#11

Rob, 

Thanks for chiming in here. I agree the concept of re-creating a native UI element is daunting. While the votes are pouring in…

I think there is still room for Corona Labs to publish a text entry widget that does what you have been recommending we do in text handling. In other words, create a native text entry box offscreen, move data back & forth etc. By the way, there is not even a good official sample of doing this (to the best of my knowledge)… For starters why not give us a rock solid sample doing this properly… 

Moving forward, best would be a text entry widget that does all the background grunt work in setting up offscreen native text boxes etc. You know it can be done as this is what you have been recommending we do all along. All we need is to have Corona Labs do it for us in the widget form and support it going forwards. 

How does this sound? Thanks,

Kerem

#12

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. 

#13

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. 

#14

#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

#15

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.

#16

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.

#17

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

#18

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

#19

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. 

#20

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