Hi form, What error does it throw? It might not be related to the textFields as they are running fine on iOS and Android devices but simply to the simulators on PC The simulators on Mac are fine too. Atanas
Just got this response to my bug report:
Hello,
Thanks for filing the bug report and the test code.
I did verify there is a bug in build 2100 regarding the color values of object:setTextColor for native objects. It’s still using 0:255 color values instead of 0:1. I’ll send this off to Engineering for a fix.
The setFillColor method is not implemented for native display objects. I verified that it generates a runtime error on Mac, iOS and Android. Windows doesn’t support native objects so it’s not supported there. You need to use setTextColor instead.
I’m glad we got the 0:1/0:255 thing cleared up, but I’m with @ksan on this one. It’s inconsistent to keep setTextColor for native objects after the push to move everything else to setFillColor.
Yep, I’m in mind with you, if we’re switching everything, also, I didn’t find anywhere in the documentation a mention of the fact that native text field will keep the original method, it was stated that setTextColor is deprecated, and I should use setFillColor.
Well, now we know, and it wasn’t too hard to convert back only the native text fields.
@Brent any update on this issue? Will setFillColor not be implemented for native text fields? Can the docs be updated to state this if so?
Hi @max84,
The issue with the 255-based thing will definitely be fixed. However, I believe the API name will remain “setTextColor()” for native text input fields/boxes, because it simply makes more sense from a user standpoint in this particular case. I realize it’s not consistent with regular text, but if we changed it, then we would receive support issues that setting the “fill” color was changing the text color instead of the field’s background color.
This may change and it’s not the official answer at this time, but I encourage you to keep using “setTextColor” for native fields.
Sincerely,
Brent Sorrentino
@Brent, thanks for the clarification. I agree it’s more semantic to keep setTextColor for native text, but stating that’d you get more support issues for incorrect expectations is moot. The issue is that the docs state setTextColor is deprecated, but in reality is the only way to get setFillColor working for native text fields. While this is being decided, could we have some clarification added to the docs?
Hi @max84,
I am currently going through all of the documentation, fixing instances of setTextColor (where it shouldn’t be), 255-based notations, reference point citation, etc. It’s a gradual process, underway at this time.
Brent
Which is exactly why a number of us wrote about this same topic when display.newText() was made to use setFillColor() to change the color of text. Just can’t understand why a SDK would not aim to be consistent.
display.newText’s are rendered graphics in the display library. You are technically setting the fill color of the graphic. All display.* uses setFillColor. The native.* context is more Text, not filling a graphic so setTextColor() makes more sense.
Rob
Ah makes sense of course if you look at it that way… Problem is…
We are all here because we chose to program in a “High-level programming language” which in general is expected to abstract the details of how a program actually runs on the computer and offer the programmer a natural language (as in… English) interface to those pesky 1s and 0s…
In other words, we shouldn’t have to remember how a word is drawn on the screen and then say therefore I will color this one with setFillColor() while I will color that other one with setTextColor()… It just doesn’t make sense to have two different ways to color text. Please pick one or the other and abstract the intricacies.
Your honor, I rest my case! :)
I believe this is related :
2013.2113
Mac/iOS: setTextColor now works correctly for 0-1.0 rgb ranges casenum:28862
If you’re using native.newTextField, you’ll want to make sure you’re using setTextColor rather than setFillColor. Does that solve your issue?
No, since setTextColor is not supported anymore in Graphics 2.0, it was supposed to be replaced by setFillColor, but it does not work, and generate and error, but thanks for the effort.
To make this clear, single input text field:
NOT\_SO\_WORKING\_TEXT = native.newTextField(100,100,200,70); NOT\_SO\_WORKING\_TEXT.font = native.newFont(native.systemFontBold, 16); NOT\_SO\_WORKING\_TEXT.text = "AAAA"; NOT\_SO\_WORKING\_TEXT.hasBackground = false; NOT\_SO\_WORKING\_TEXT:setFillColor(1,1,1);
the setFillColor line generate an error:
Runtime error ...sers/formatc/Documents/Corona Projects/test/main.lua:13: attempt to call method 'setFillColor' (a nil value)
Works fine on PC simulator, works fine on android, does not work in Mac simulator, does not work in iOS device.
Anyone with a solution??
To be clear max84, setTextColor does work, the point is it’s not supposed to work.
In Graphics 2.0 setTextColor was replaced with setFillColor, now, the situation is that if I use setFillColor, like I’m supposed to, on PC for android, it works fine, both on PC and on device, but the same code, in the same build, only in the Mac version, generates error, and the other way around too, if I use setTextColor on Mac, it works just fine, and compiles fine, but it will generate errors when I’m trying to use it on PC and android.
I’m using the latest build which uses Graphics 2.0, and it’s one of the changes introduced, deprecating setTextColor and changing it with setFillColor, but it seems that in the latest release only half the job was done.
@formatc You are correct! I forgot native API stuff switched over as well. You’re also correct in that setFillColor does not work on native.newTextField (I can confirm this). I can use setTextColor without issue in the simulator running on a Mac, but as you stated - that shouldn’t work.
Lets hope this issue is being resolved since I don’t want to simply throw away 2 days of converting a huge amount of code and replace them with more days of work, plus the need to have 2 different versions of code for PC (my normal working environment) and Mac (which I use to compile my projects for the iOS).
To tell you the truth, I simply don’t see the reason behind changing the previous RGB system with a 0-1 system to defining colors, now if I want to color something I need to calculate everything, I have the RGB I need from any graphical program, but now I need to to do some math to know what I need to put in, for RGB 127,50,180 I would need to start calculating (1/255)*127 to get R and so on… why would take a step like that, how does that makes out lives any simpler? but it’s off subject, I’m just ranting while waiting for a reply.
I think I’ll submit a bug report, to help me pass the time…
Yeah, I don’t like the change to RGBA values either… but the reasoning has been described here: http://forums.coronalabs.com/topic/40216-why-change-the-color-parameter-values/?hl=+graphics++2.0++colors
I usually just use my values from the mockup and divide them, like so:
[lua]object:setFillColor(127/255, 50/255, 180/255)[/lua]
Dumb, but oh well. I’m curious though, does this work for you on PC/Mac?
[lua]object.fill = {127/255, 50/255, 180/255}[/lua]