setFillColor in graphics 2.0 text input do not work on Mac simulator and iOS device!

I’ve worked my ass off these past couple of days adapting my project to graphics 2.0, on my PC, and now when I’m all done and tested, I’ve copied the code to my Mac so I could compile an iOS version, but “setFillColor” that I use to set the color of text in input text field generate an error both on the simulator and on the device!!

I need someone who can tell me I didn’t throw away 2 days of my life on changing my project just to find out now that  the compiler is full of bugs.

I’m using build 2013.2100, currently the latest build, help help help someone!!

Thanks.

Yuval.

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]

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 :slight_smile:

 

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. :slight_smile:

Hi all,

If I understand the issue here, it’s that “setFillColor” doesn’t set the text color on native text input boxes?

Brent

@Brent: That is correct.

If you use “setTextColor” (only on native fields), does it ever throw an error or warning?

@Brent: No. Setting the text color using setTextColor works, with no error. (Mac)

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 :slight_smile:

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.