[solved] How Do I Get The Colours That I Want? (1 Viewer)

[CyberSimian]

On reading the code you will see that the value will be interpreted as a named colour (eg. "gold") if the value contains any characters outside 0-9A-Fa-f. That's exactly what's going to happen if you include a # prefix. Therefore catavolt's advice to not include the prefix is good.

That is not what the Wiki says!

The Wiki implies that either decimal or hexadecimal values can be specified (and gives an example). A value containing one or more hexadecimal digits is clearly hex (if it is valid). But if a value contains only decimal digits (e.g. 12345678), how does the skin engine know whether the value is decimal or hex? I imagined that that was what the "#" prefix is for:

12345678 -- a decimal number
#12345678 -- a hexadecimal number

Also, I have just tried both "cc00ff00" and "#cc00ff00" (without the quotes), and both give the same result -- a light green background.

-- from CyberSimian in the UK

 

[ajs]

@mm1352000
In WIKI: https://www.team-mediaportal.com/wiki/display/MediaPortal1/Colors

<textcolor>White</textcolor>
<textcolor>#20FFFFFF</textcolor>
<textcolor>#330099</textcolor>
<textcolor>Gainsboro</textcolor>
<!-- specify a named color with non-default alpha (using hex, preferred) -->
<textcolor>White:#60</textcolor>
<!-- not using hex -->
<textcolor>White:96</textcolor>

The code handles these values is one: https://github.com/MediaPortal/Medi...al/Core/guilib/GUIControlFactory.cs#L261-L263

          if (String.Compare(valueName, "textcolor", StringComparison.OrdinalIgnoreCase) == 0 ||
              String.Compare(valueName, "colorkey", StringComparison.OrdinalIgnoreCase) == 0 ||
              String.Compare(valueName, "colordiffuse", StringComparison.OrdinalIgnoreCase) == 0)
          {

 

[ajs]

When we specify the color with # Media portal thinks that it is a named color And using the function: Color.FromName But she knows how to work with string type #FFFFFFFF ... https://github.com/MediaPortal/Medi...aportal/Core/guilib/GUIControlFactory.cs#L305
When we not specify the color with # Media portal use ColorTranslator.FromHtml https://github.com/MediaPortal/Medi...aportal/Core/guilib/GUIControlFactory.cs#L311
Both methods should work. #FFFFFFFF and FFFFFFFF ...
How to convert a color you can see: https://referencesource.microsoft.c...ystem/Drawing/Advanced/ColorTranslator.cs,228

 

[mm1352000]

That is not what the Wiki says!

The wiki may well be wrong. Its happened in the past and I'm sure it will happen again in the future.

...how does the skin engine know whether the value is decimal or hex?

As you can see from the code, the engine doesn't appear to explicitly handle decimals for the colordiffuse, colorkey and textcolor elements/attributes. I can't say more than that.

I imagined that that was what the "#" prefix is for

Again, as you can see from the code, it appears that your imagination was wrong.

Also, I have just tried both "cc00ff00" and "#cc00ff00" (without the quotes), and both give the same result -- a light green background.

From what I can see, the #cc00ff00 can only ever be recognised as a valid colour in one scenario due to a quirk of the engine's colour caching mechanism.

Use of cc00ff00 (always valid) will cause the engine to cache the corresponding colour (ARGB cc00ff00) with cache key #cc00ff00:
https://github.com/MediaPortal/Medi...aportal/Core/guilib/GUIControlFactory.cs#L311

If you subsequently attempt to use colour #cc00ff00, the engine code will start with the assumption that you're attempting to use a named colour. That assumption is based on the presence of the non 0-9A-Fa-f character (#) in the colour value:
https://github.com/MediaPortal/Medi...al/Core/guilib/GUIControlFactory.cs#L267-L278

So, isNamedColor will be true even though we know that #cc00ff00 is not and never has been a valid named colour.

We can ignore the next little section of code because #cc00ff00 does not contain a colon:
https://github.com/MediaPortal/Medi...al/Core/guilib/GUIControlFactory.cs#L284-L304

Now we come to the revelation. Before attempting to convert the assumed-to-be-valid-named-colour to it's ARGB representation, the engine checks the cache for the corresponding key. The key for a named colour is just its name, which in this case is #cc00ff00:
https://github.com/MediaPortal/Medi...aportal/Core/guilib/GUIControlFactory.cs#L305

If you recall, the cc00ff00 colour was previously also stored with that same #cc00ff00 cache key.

...and now you should understand what's going on.

Had you not previously used that cc00ff00 colour, the engine would try to convert #cc00ff00 to it's ARGB representation using Color.FromName(). That function silently fails and returns a colour with ARGB value 0 (black). As a result, the engine will cache #cc00ff00 as ARGB 0. Subsequent attempts to use either cc00ff00 or #cc00ff00 would result in use of ARGB 0 instead of the desired ARGB cc00ff00.


So I repeat: catavolt's advice to not use the # prefix is good.


You have the code so you can see how it works. I advise you to use it and not get hung up on what the wiki says. Please do update the wiki if/where it is not correct. This would be much appreciated.


DISCLAIMER:
I'm not a skin engine expert, and I didn't write the code or the wiki content that has been linked here. I'm simply trying to assist you towards an answer to your question(s).

 

[ajs]

So I repeat: catavolt's advice to not use the # prefix is good.

It is necessary to modify the wiki, or remove in source code the # character at the beginning of the line. Or do not consider the color with # at the beginning, as a named.

 

[mm1352000]

It is necessary to modify the wiki...

I recommend this one to avoid breaking existing skins.

 

[ajs]

I recommend this one to avoid breaking existing skins.

How can it affect the current skin? If now no one uses the # symbol in the color designation in the fields of: textcolor, colorkey, colordiffuse?

 

[CyberSimian]

From what I can see, the #cc00ff00 can only ever be recognised as a valid colour in one scenario due to a quirk of the engine's colour caching mechanism. Use of cc00ff00 (always valid) will cause the engine to...

Crikey! It will take me some time to digest all that. But thank you for taking the time to look at the code and then explain it to me.

It also explains some inconsistencies in the results during testing, but for which I could not identify any pattern. Now it seems (if I have understood correctly) that the behaviour depends on what value was used previously, thereby confusing the results of the tests.

I will remove all the "#" and see what result I get. Thank you @mm1352000 , @catavolt , @ajs .

-- from CyberSimian in the UK

 

[mm1352000]

How can it affect the current skin? If now no one uses the # symbol in the color designation in the fields of: textcolor, colorkey, colordiffuse?

You don't know that no one uses the # symbol in the color designation. Any third party skin including unmaintained skins could be using that.

 

[mm1352000]

Crikey! It will take me some to digest all that.

Indeed, it took me quite a long time to figure it out.

But thank you for taking the time to look at the code and then explain it to me.

You're welcome.