I think it will be fine on all Android devices, since we have the background off, it won’t matter.
Rob
Ok. Its best to try on your newer Android device and see how it goes then before committing. Look forward to your findings. Thanks much!
It’s fine on my Nexus 7 running 4.4
Rob
Super. Then the code used in CL NativeDisplayObjects sample
local tHeight = 30 if isAndroid then tHeight = 40 end
is a viable solution for all Android editions. Glad we could get to the bottom of this.
Going back to the original topic… The feature request votes now stand at 296 + 167 for this very much sought out capability. Rob’s tutorial was a good start in the right direction but I sure hope it won’t be the last we hear from Corona Labs on this key topic. Bumping this one up so it can get some more attention and votes. Thank you!!!
Added my 3 votes 
Thank you for your support! Now 272!!!
And welcome on board by the way. Great 1st post. Thanks.
Thanks for the welcome - using it for business type apps and battling with the usual suspects - buttons, data entry controls , layout system
Bump!
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!
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…
Anyone know when the finalize event was added ?
Am using 1202 (last public release before Graphics 2) and can’t get it to fire using Robs example.
The problem am having is adding the code to a StoryBoard Overlay and getting it to disappear when the overlay closes.
I have added textField.RemoveSelf() to exitScene but that does nothing, you can still see the text on the screen when the overlay closes.
Dave
I’m not sure when it was added, but my sample was only tested on 2076 and later. You can use a technique where you override the removeSelf() function on the field group by making a copy of removeSelf() then writing yours that removes the native.newTextField() then calls the saved real removeSelf().
There will be other G2.0 vs. G1.0 changes that will need to be made as well.
Rob
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
Hi Guys.
Are each one working in your own text widget or do we have 1 common repository for everyone to contribute?
I created my own text widget and works ok (the only problem is that difference font size that everyone faces…). I can open source it so everyone can contribute or I will be more than happy to contribute if anyone has a text widget better than mine…
Mine isn’t anywhere sharable yet. It’s in my local copy of the business sample app.
Rob
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?
Renato, we are all doing our own thing as a most productive way I’ll be happy to merge with you, shoot me a private message Atanas
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
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