Is there way to make the native textBox to adjust its height to fit the entire text? (and thus not have a vertical scroll)
No. And this is because a TextBox is multiline and there is no way to know *how* to auto-size it. TextBoxes are designed to be vertically scrollable and they have no idea how many minimum lines should be displayed, leaving the rest to be scrollable. No UI framework that I’m aware of offer this capability. Typically, UI designers just hard-code the height and set the font size to be the same as the rest of the UI.
Also, if the TextBox you are setting up is not editable, then I suggest that you use display.newText() instead where you set a wrapping width, but leave out the height. This will display all of lines of the text… up until the max texture size, which will get clipped.
Thanks for the reply Joshua.
Actually I am using textBox exactly to overcome an issue with display.newText (that emojis are not shown with color).
Found another post on the forum about a dev that was using newText to estimate the text height and then use it on textBox. Unfortunately that work-around does not work very well because even using systemFont and same font size, sometimes the text inside newText ends up with a smaller number of lines. So i thought in asking here if someone else have another suggestion.
I’m thinking that the best work-around to do is to replace the emoji Unicode characters in the string with their 
equivalent and continue to use display.newText(). That would be the fastest solution. The following link documents the Unicode character codes for emoji characters.
https://en.wikipedia.org/wiki/Emoji
The above is the fastest solution. Us making a new API for 32-bit color text objects that works on all platforms would be more work than it’s worth. Especially since it’ll take 4x the memory and 4x times the CPU time to generate text bitmap/texture (8-bit grayscale text bitmap vs. 32-bit color text bitmap). And trying to rig a native multiline TextBox to display all lines, which they’re not really designed to do (they’re designed to have fixed height with vertical scrollbar), would be more trouble than it’s worth as well.
Thanks for the suggestion.
Unfortunately, that would not be an option. The client wants the emoji to appears equal as they appear on the Twitter (the app would display a twitter feed).
Right now I am using the textBox option. But even now I have the problem that the http links inside the textBox are not “tapable”. So now I am thinking in trying to add a support to the emoji manually on newText by identifying them inside the text (thanks for the link with the emoji codes) and inserting in their position. If I end up doing that, I will post here the results for future devs.
Perhaps another solution is to find a TTF/OTF font file that supports grayscaled (black & white) emoji icons?
Actually the newText shows the Emoji, but only in monocolor.
Look the difference between an Emoji on newText versus on textBox. (both using native.systemFont with fontSize 12 - screenshot from an iPhone 6)
I understand that… but our display.newText() objects are ***designed*** to be 8-bit grayscaled bitmaps that are color blended with an OpenGL polygon. That’s by design. And this allows everyone to easily change the color, apply gradients, and other effects on text in a very fast efficient manner in OpenGL without having to re-generate a new text bitmap. Versus generating a 32-bit color text bitmap which can support a 32-bit color emoji icon, but this 32-bit color text bitmap would have to be re-generated when you want to change its color… and this is a huge-Huge-HUGE fundamental design/implementation difference where it would have to be a brand new API that has to be implemented on all platforms. As in how a 32-bit color text is rendered to bitmap and OpenGL would be completely different.
Bottom Line: display.newText() can’t ever support 32-bit color emoji icons. It can only support 8-bit grayscaled character/glyphs.
But the solution I posted up above where you can use a font that supports grayscaled emoji gryphs will work. They won’t match what you see on the virtual keyboard, but at least they’ll be legible because the font’s emoji glyphs are designed to be grayscaled.
Have you considered a webView for this?
So, I was able to use the native.textBox to show the emojis (I used a display.newText to roughly calculate the height of the textBox)
Unfortunately now I have the problem that native objects appears always on top, and the app has a nav bar on top and the textBox is appearing above the navbar (the scrollview mask does not hide the native obj).
My next attempt will use Rob suggestion to use a webView. The sad side of that is that I will have not only to show the text with emoji but also implement the scrollview and the other objects that appear on the screen…
The webview is still going to set on top like the textbox.
Rob
I know… that is why I cannot use the webview just to display the text (it would behave as the native.textBox), I would need to use a webview that fills all my screen minus the topbar (which in my app is basically a scrollview with the text feed).
But I changed my mind in trying the webview now. I found the emojis icons on in the internet and I will just use them as image, replacing the Corona mono-color emojis.
If I succeed on that, I will later post the code on github for other users.
No. And this is because a TextBox is multiline and there is no way to know *how* to auto-size it. TextBoxes are designed to be vertically scrollable and they have no idea how many minimum lines should be displayed, leaving the rest to be scrollable. No UI framework that I’m aware of offer this capability. Typically, UI designers just hard-code the height and set the font size to be the same as the rest of the UI.
Also, if the TextBox you are setting up is not editable, then I suggest that you use display.newText() instead where you set a wrapping width, but leave out the height. This will display all of lines of the text… up until the max texture size, which will get clipped.
Thanks for the reply Joshua.
Actually I am using textBox exactly to overcome an issue with display.newText (that emojis are not shown with color).
Found another post on the forum about a dev that was using newText to estimate the text height and then use it on textBox. Unfortunately that work-around does not work very well because even using systemFont and same font size, sometimes the text inside newText ends up with a smaller number of lines. So i thought in asking here if someone else have another suggestion.
I’m thinking that the best work-around to do is to replace the emoji Unicode characters in the string with their equivalent and continue to use display.newText(). That would be the fastest solution. The following link documents the Unicode character codes for emoji characters.
https://en.wikipedia.org/wiki/Emoji
The above is the fastest solution. Us making a new API for 32-bit color text objects that works on all platforms would be more work than it’s worth. Especially since it’ll take 4x the memory and 4x times the CPU time to generate text bitmap/texture (8-bit grayscale text bitmap vs. 32-bit color text bitmap). And trying to rig a native multiline TextBox to display all lines, which they’re not really designed to do (they’re designed to have fixed height with vertical scrollbar), would be more trouble than it’s worth as well.
Thanks for the suggestion.
Unfortunately, that would not be an option. The client wants the emoji to appears equal as they appear on the Twitter (the app would display a twitter feed).
Right now I am using the textBox option. But even now I have the problem that the http links inside the textBox are not “tapable”. So now I am thinking in trying to add a support to the emoji manually on newText by identifying them inside the text (thanks for the link with the emoji codes) and inserting in their position. If I end up doing that, I will post here the results for future devs.
Perhaps another solution is to find a TTF/OTF font file that supports grayscaled (black & white) emoji icons?
Actually the newText shows the Emoji, but only in monocolor.
Look the difference between an Emoji on newText versus on textBox. (both using native.systemFont with fontSize 12 - screenshot from an iPhone 6)
I understand that… but our display.newText() objects are ***designed*** to be 8-bit grayscaled bitmaps that are color blended with an OpenGL polygon. That’s by design. And this allows everyone to easily change the color, apply gradients, and other effects on text in a very fast efficient manner in OpenGL without having to re-generate a new text bitmap. Versus generating a 32-bit color text bitmap which can support a 32-bit color emoji icon, but this 32-bit color text bitmap would have to be re-generated when you want to change its color… and this is a huge-Huge-HUGE fundamental design/implementation difference where it would have to be a brand new API that has to be implemented on all platforms. As in how a 32-bit color text is rendered to bitmap and OpenGL would be completely different.
Bottom Line: display.newText() can’t ever support 32-bit color emoji icons. It can only support 8-bit grayscaled character/glyphs.
But the solution I posted up above where you can use a font that supports grayscaled emoji gryphs will work. They won’t match what you see on the virtual keyboard, but at least they’ll be legible because the font’s emoji glyphs are designed to be grayscaled.
Have you considered a webView for this?