If you use “setTextColor” (only on native fields), does it ever throw an error or warning?
Hi, It sets the color, but uses the old scheme of RGB, its not converted to G2 -so you need to still use your old colors Cheers Atanas
Hi guys,
Thanks for the clarification.
The fact that this doesn’t use the new 1-based RGB settings is likely a bug, and I’ll report it. As for changing this to “setFillColor”, I don’t think that will be done because, in this case, :setTextColor() actually makes sense from a user standpoint. With a native text box, “fill” would hint at a fill color of the background (if you don’t hide it), not the text color. I realize this goes against how normal text objects now use :setFillColor(), but in this case it seems logical to set the text color, not the fill color. Those are my thoughts at least… I don’t know what the engineers will say, but I think this was intentional.
It also shouldn’t work one way on Android but another way on iOS. I’ll file that with the report as well.
Best regards,
Brent
This is very inconsistent. There was a long explanation on why we should transition to :setFillColor() in general and why it makes sense etc. Now to argue that for native text objects we should stay with :setTextColor() very counter-productive. Please pick one or the other but shoot for consistency rather than trying to rationalize what appears to be a simple oversight. Just my humble opinion.
Thanks Brent,
I agree with the 1-based RGB bug, it needs to be fixed as it took me some time to figure out why all colors would display as black 
Atanas
Brent, the problem is not that it’s just not working, using setFillColor, but it also throws an error, stopping the script!
Meaning that if I have a native text field now, which I want to change the color of, I would need to have 2 sets of code, one for Android/PC and one for iOS/Mac, or else I would have constant errors! the one works on PC/Android but gives an error on iOS/Mac, the other works on iOS/Mac, but gives off errors on PC/Android, completely messing up the idea of a single code for both platforms!
Hope this clears it up.
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