Anyone tried the new newTextField?

Solar2D Daily Builds and Public Releases
#1

I’m working on an a release in the next days and can’t update to this build, but I’m curious, is Coronas biggest problem fixed? :) 

#2

Hi @jonjonsson,

In our testing, yes, all of these issues are now fixed, but of course we want all of you Pro/Enterprise developers to experiment with it using build #2520 or later.

Also, you’ll need to understand these changes better before you proceed. The documentation for the daily build is fully updated, but this week’s tutorial is a “one-stop” place to learn about these new features:

http://coronalabs.com/blog/2014/12/16/tutorial-new-native-text-input-features/

Take care,

Brent

#3

A miracle so it seems. After all that talk of why this can’t be done… So it turns out where there is will there is a solution. It was always the will problem. Whoever made the decision to invest energy in resolving this long standing embarrassment deserves a big thank you. Well done.

#4

Awesome!!  Was wondering if I should stay clear of widgetstown’s neweditfield?  Or should this still work no problem?

Thanks

#5

Just to be clear.  For the Windows simulator, native.newTextField() and native.newTextBox() cannot be implemented due to Microsoft’s implementation of OpenGL.  These are still native objects that sit above OpenGL and it’s not an OpenGL object.  This addresses the various problems getting heights and font sizes correct which was one of the biggest frustration points for people trying to integrate this API call into their code. 

Now that this is in place as well as allowing native text objects to be part of groups with regards to moving them, the folks at WidgetTown can build a better newEditField() for you, or it should be easier to improve the widget.newTextField() option we blogged about a few months ago. 

Rob

#6

Hi @jonjonsson,

In our testing, yes, all of these issues are now fixed, but of course we want all of you Pro/Enterprise developers to experiment with it using build #2520 or later.

Also, you’ll need to understand these changes better before you proceed. The documentation for the daily build is fully updated, but this week’s tutorial is a “one-stop” place to learn about these new features:

http://coronalabs.com/blog/2014/12/16/tutorial-new-native-text-input-features/

Take care,

Brent

#7

A miracle so it seems. After all that talk of why this can’t be done… So it turns out where there is will there is a solution. It was always the will problem. Whoever made the decision to invest energy in resolving this long standing embarrassment deserves a big thank you. Well done.

#8

Awesome!!  Was wondering if I should stay clear of widgetstown’s neweditfield?  Or should this still work no problem?

Thanks

#9

Just to be clear.  For the Windows simulator, native.newTextField() and native.newTextBox() cannot be implemented due to Microsoft’s implementation of OpenGL.  These are still native objects that sit above OpenGL and it’s not an OpenGL object.  This addresses the various problems getting heights and font sizes correct which was one of the biggest frustration points for people trying to integrate this API call into their code. 

Now that this is in place as well as allowing native text objects to be part of groups with regards to moving them, the folks at WidgetTown can build a better newEditField() for you, or it should be easier to improve the widget.newTextField() option we blogged about a few months ago. 

Rob