Roku Developer Program

[EugeneZ]

Most often we create label in XML, then write in component code something like

m.myLabel.color="0x72D7EEFF"

Color is in RGBA format, everything is good

BUT: recently I created a bunch of labels like this:

winLabel = m.top.createChild("Label")

winLabel.color = "0xFFFFFF" 'should be cyan but shows as white!

winLabel.color = "0xFFFF"      'should be blue but shows as cyan!

It is like label's color is treated as RGB, not RGBA

HOWEVER when you read it after setting to "0xFFFF" it reads back as "0xFFFFFF"

Can anyone explain this magical behavior? Is this related to labels being created at run-time or something else?

[renojim]

I think it appends "FF" to any string that isn't 4 hex bytes long assuming you want 0xFF as the A component.  That's if you give it something like "0xRRGGBB" - it's the same thing as "0xRRGGBBFF", so your "0xFFFFFF" is really "0xFFFFFFFF".  What it does if you don't give it 3 hex bytes for RGB I've never tried.  Don't ever expect Roku to do something logical.  Always specify values for R, G, and B and add the A if you want something other that 0xFF.

[speechles]

You are incorrect about the colors created by those strings.

0x00FFFF is cyan. 0xFFFFFF is white. 0x0000FF is blue.

winLabel.color = "0xFFFFFF"
(what the Roku applies) "0xFFFFFFFF" is white with no transparency.

winLabel.color = "0xFFFF"
(what the Roku applies) "0x00FFFFFF" is cyan with no transparency.

The colors are always determined by RGB. You only apply the alpha if you need the transparency for blending or what not.

[EugeneZ]

> winLabel.color = "0xFFFFFF"
> (what the Roku applies) "0xFFFFFFFF" is white with no transparency.

My question exactly. Why does it apply a number other than what I explicitly gave it?

When ROKU sees 0xFFFFFF it _guesses_ that I forgot to specify transparency?

And when I set 0xFF7F it will _guess_ that I mean green 0x0FF + blue 0x7F,

not blue 0xFF + Alpha 0x7F ?

If that is correct, this looks like a **bleep** of "undocumented feature"

[renojim]

You can either fight Roku shortcomings or work around them.  I choose the latter.  It's much less frustrating.  I don't see any reason to try to abbreviate blue as "0xFFFF".  The bottom line is always specify all 4 bytes and you won't be surprised with what you get.

[EugeneZ]

>I don't see any reason to try to abbreviate blue as "0xFFFF". The bottom line is always specify all 4 bytes >and you won't be surprised with what you get.

Do you mean that language works differently if I write "0xFFFF" and "0x0000FFFF" ?

Or that I need so write "0x0100FFFF" to give it something in the 4-th byte?

BTW 0xFFFF works great as blue for Rectangle. Is treatment of color different between components?

I am looking for a comment from developers - how is that thing *supposed* to work ?

[renojim]

I can only tell you what I do.  If I want blue I put in "0x0000FF" (R=00, G=00, B=FF) and let it assume the FF for A (i.e. "0x0000FF" is the same thing as "0x0000FFFF").  The fourth byte is the A value and appears to be optional if you want 0xFF.  It gets even more confusing in the rare instances where you have to give a color as an Integer and not a string.  I can't think of one of those instances, but I did come across one recently.  In those cases I think your method of leaving out colors would work (e.g., &hFF is black, &hFFFF is blue, etc.).

I've dealt with Roku for far too long to try to fight something like this.  If you think their documentation sucks get used to it.  Trying to get them to fix it is an exercise in futility.  My most recent report of a pretty major bug elicited no response from Partner Success 🙄 .  This doesn't even come close to that.

[speechles]

The issue is the behavior of omitting color information is an undocumented feature.

Since this method of storing colors isn't intended by the developers to be used this way. Each different component (rectangle color, poster blendcolor, etc) can produce a different color when you feed it an incomplete color string of the RGB information.

A good question is why do you need to use shorthand for the colors? Why must it fill in the blanks? Is there a good reason?

You need to instead help the Roku where it fails you. Give it all the information it needs to do the job. All the rest of us are in the same boat. It is just the way it is. You are not suffering alone... lol. Take care and be well. Merry Chistmas. Happy new year. And best wishes. 🙂

[EugeneZ]

Ok, I think I understand.
I assumed that assignment with a string simply leads a type conversion of that string to an integer,
just a call to Val() with radix 16. Or strtoul if it is done by deeper levels.
Pretty natural assumption, no?

With integers, there is no difference between &H00FFFFFF and &HFFFFFF.
People just write a number. And people rarely write leading 0s.

But this case - it is not just a type conversion, there is some additional logic.

SO: the guidance, as I understand, is:
for colors you should either give an integer, or a string with all leading zeros. Right?

This raises related questions: is this feature unique to hexadecimals in a string?
Would string with decimal "255" considered incomplete?
Is this feature unique to colors, or other fields have that too?

Thanks!

[renojim · Accepted solution]

@EugeneZ, yeah, when it comes to Roku don't assume anything is logical.

I think you're thinking about it too much.  It's generally only an issue with colors and only really became an issue when Scene Graph appeared and most things were initialized via XML entries which are all strings - it doesn't understand a string like "&h00FF" appearing in XML, but you can be confident &hFF == &h00FF in code.   In other words, the ways of specifying an Integer in code are not the same way you'd specify an Integer in XML.  RGBA hexadecimal strings are unique to colors (at least I don't believe I've seen any kind of hexadecimal strings used anywhere else).

I'd say it's not an issue in code, but there's still plenty of places where colors are specified as a "RGBA hexadecimal string" which I couldn't find any definition of in Roku's documentation.  My definition would be a string starting with "0x" followed by three 2-character hex entries for R, G, and B with an optional forth for A.  I don't think I'd attempt to use a hexadecimal string in XML for anything other than a color.  It may work, but why risk it?  Like I said, don't assume anything is logical when it comes to Roku.

If you start doing roScreen stuff then colors are generally specified as Integers in your code and you can be pretty confident that there's no funny business going on - no need for leading zeros or any other strangeness.  Be happy roImageCanvas isn't still around which used yet another way of specifying colors.

If you're going to be a Roku developer you really have to roll with the punches or it will make you crazy.