So I have seen many other apps, that allow you to type things in… most of them with fancy input boxes. Is native.newTextBox (the big ugly white textbox) the only one we have access to? I didn’t see anything that really lets us customize it very much. Any tutorials or anything for making other ones?
-
Is this an Android or iOS question?
-
There are ways to customize it (see the docs and read the field and method definitions carefully; experiment to see what they do.)
https://docs.coronalabs.com/api/type/TextField/index.html
- I asked #1 because what you can do is a bit different between Android and iOS to customize the look.
I’m not aware of any tutorials or samplers that explore this extensively.
You’re going to need physical test devices to see the results of your testing. When in the simulator you get the Windows/OS X native inputs which are NOT the same as the mobile ones.
I know that in some of my prior apps I have:
- customized the font
- customized the background
- customized the color of the outline
- given rounded outlines
Your other option is to make your own text field library and your own keyboard.
There used to be a paid library for this but it is no longer supported, which is a real shame because the solution was beautiful.
This is an old app I wrote that has some minor tweaks:
https://play.google.com/store/apps/details?id=me.menu.eater&hl=en
If you download it, use the ‘email login’ and it will bring up a screen with minorly tweaked text fields. In this case, the client wanted a white background so this isn’t that big a deal:
- custom font
- colored and rounded text field outline
Well, humm I have looked at the API, and I didn’t see anything that would let you change background color/or use a picture. All of which would be great.
I could do with just colored text and a black background.
You can have a transparent background in your text field and put a display object behind it.
Rob
I know this is slightly off-topic, but since Klynt brought up a good point about native.newTextBox( )/native.newTextField…
Is there any reason why the above is a native object and not a display object???
The fact that native.newTextBox( )/native.newTextField is not a display object (and thus not part of the display hierarchy) creates so many limitations I can’t even enumerate them…
So my question is: does Corona have any plans to make the it a display object any time in the near future?
Let me answer the second question first, no, we will not be creating a display.* based version of the textField/textBox. Why?
On mobile devices, the keyboard is native. To show it and let you use it means native.
Well then, build our own keyboard using display objects and touch handlers…
While that is technically possible, it’s not practical. Corona is an internationally used product. A hand-built keyboard would have to support dozens of language keyboards, emojis, left-right, and right-left languages, multiple keyboard types (like Twitter, email, URLs, etc.) It would need to support the predictive word selection, auto-correct, and all the features you expect out of the existing native keyboards including custom keyboard support.
It would take our entire team a couple of years to build a functional keyboard system and we would get no other work done.
Rob
-
Is this an Android or iOS question?
-
There are ways to customize it (see the docs and read the field and method definitions carefully; experiment to see what they do.)
https://docs.coronalabs.com/api/type/TextField/index.html
- I asked #1 because what you can do is a bit different between Android and iOS to customize the look.
I’m not aware of any tutorials or samplers that explore this extensively.
You’re going to need physical test devices to see the results of your testing. When in the simulator you get the Windows/OS X native inputs which are NOT the same as the mobile ones.
I know that in some of my prior apps I have:
- customized the font
- customized the background
- customized the color of the outline
- given rounded outlines
Your other option is to make your own text field library and your own keyboard.
There used to be a paid library for this but it is no longer supported, which is a real shame because the solution was beautiful.
This is an old app I wrote that has some minor tweaks:
https://play.google.com/store/apps/details?id=me.menu.eater&hl=en
If you download it, use the ‘email login’ and it will bring up a screen with minorly tweaked text fields. In this case, the client wanted a white background so this isn’t that big a deal:
- custom font
- colored and rounded text field outline
Well, humm I have looked at the API, and I didn’t see anything that would let you change background color/or use a picture. All of which would be great.
I could do with just colored text and a black background.
You can have a transparent background in your text field and put a display object behind it.
Rob
I know this is slightly off-topic, but since Klynt brought up a good point about native.newTextBox( )/native.newTextField…
Is there any reason why the above is a native object and not a display object???
The fact that native.newTextBox( )/native.newTextField is not a display object (and thus not part of the display hierarchy) creates so many limitations I can’t even enumerate them…
So my question is: does Corona have any plans to make the it a display object any time in the near future?
Let me answer the second question first, no, we will not be creating a display.* based version of the textField/textBox. Why?
On mobile devices, the keyboard is native. To show it and let you use it means native.
Well then, build our own keyboard using display objects and touch handlers…
While that is technically possible, it’s not practical. Corona is an internationally used product. A hand-built keyboard would have to support dozens of language keyboards, emojis, left-right, and right-left languages, multiple keyboard types (like Twitter, email, URLs, etc.) It would need to support the predictive word selection, auto-correct, and all the features you expect out of the existing native keyboards including custom keyboard support.
It would take our entire team a couple of years to build a functional keyboard system and we would get no other work done.
Rob