Text Field -> setFillColor()?

I see errors in the console in regards to the deprecated setTextColor, and the advice to use setFillColor.  There is no mention of this on the API page here http://docs.coronalabs.com/api/library/display/newText.html or http://docs.coronalabs.com/api/type/TextField/setTextColor.html

But we do have this here  http://docs.coronalabs.com/api/type/ShapeObject/setFillColor.html for a ShapeObject, but even on that page there is no addressing the new color values ( ie: value/255 ).

my apologies if I’m seeming critical, but should we assume the docs are a WIP?

Thanks in advance.

The best thing to do when you find an issue with the documentation is to hit the thumbs down button.  This actually generates a bug report to the documentation team which really helps nail down things.  

In the mean time, if you’re not are not using v1 compatibility mode then you would need to have a 0…1 based values for any color function regardless if the docs say it or not.   And display.newText now uses :setFillColor() not :setTextColor().

Rob

I would go find the thread where we previous explained it, but its probably just as easy for me to retype the answer.

There was considerable discussion among the entire team on the pros and cons of making this change.  We even tried to come up with some options.  The reason why we moved forward is that 0-255 limits you to 8 bits per color channel.  We need the engine to think in terms of 16 and 32 bits per color channel.   At some point we have to make the change.   

As noted, there is the v1 compatibility mode which lets you still use 0-255 as values for v1 API calls as well as keeps reference points around.  Any v2 type calls will use 0…1.  Secondly while we still think in 8 bit color terms, it’s easy to compute the values by doing a /255 operation.  Also, in Adobe Photoshop, if you set an image to 32 bit color, the color picker will give you the colors in their decimal values that is compatible with G2.0. 

Rob

Rob, thanks for that explanation. I think a “better” choice would have been to make all color values 0-1 when in v2 mode, both legacy and new calls. That way things are consistent. But I can see how that would bring up other problems, so you’d catch grief from *someone*! :slight_smile:

 Jay

PS - For anyone who wonders what he’s responding to, it was a post of mine that, upon further review, was deemed (by me) to be a bit on the “aggressive” side so I deleted it.

The best thing to do when you find an issue with the documentation is to hit the thumbs down button.  This actually generates a bug report to the documentation team which really helps nail down things.  

In the mean time, if you’re not are not using v1 compatibility mode then you would need to have a 0…1 based values for any color function regardless if the docs say it or not.   And display.newText now uses :setFillColor() not :setTextColor().

Rob

I would go find the thread where we previous explained it, but its probably just as easy for me to retype the answer.

There was considerable discussion among the entire team on the pros and cons of making this change.  We even tried to come up with some options.  The reason why we moved forward is that 0-255 limits you to 8 bits per color channel.  We need the engine to think in terms of 16 and 32 bits per color channel.   At some point we have to make the change.   

As noted, there is the v1 compatibility mode which lets you still use 0-255 as values for v1 API calls as well as keeps reference points around.  Any v2 type calls will use 0…1.  Secondly while we still think in 8 bit color terms, it’s easy to compute the values by doing a /255 operation.  Also, in Adobe Photoshop, if you set an image to 32 bit color, the color picker will give you the colors in their decimal values that is compatible with G2.0. 

Rob

Rob, thanks for that explanation. I think a “better” choice would have been to make all color values 0-1 when in v2 mode, both legacy and new calls. That way things are consistent. But I can see how that would bring up other problems, so you’d catch grief from *someone*! :slight_smile:

 Jay

PS - For anyone who wonders what he’s responding to, it was a post of mine that, upon further review, was deemed (by me) to be a bit on the “aggressive” side so I deleted it.