it might work, I will test it, but it’s not the issue, my point and pain is spending this time converting my project, and I’m talking about 14k lines of code, changing all the setRefrencePoint to the new anchors system, changing all the setTextColor to setFillColor, testing it on PC and android for hours on end, and then when I’m all done, happily going to compile on Mac only to see a mile long list of errors. it’s just so annoying…
Tried fill, didn’t work on Mac, pointless to try on PC.
If anyone from staff reads this, my bug report is case 28862, I think it’s a pretty large bug, so push it up 
I’m completely with you on the “this should work” and “that isn’t the issue”. I was just curious what did and didn’t work so we’d have a more testing done ahead of the bug report. I’m just as frustrated with my current G 2.0 project.
Eagerly awaiting the response from CL.
Hi all,
If I understand the issue here, it’s that “setFillColor” doesn’t set the text color on native text input boxes?
Brent
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