Hex to color ???

New comment
 

Hi,

I am building a colour scheme for me and I was using this to get the Hex-code of e.g. yellow 0xFFFF00:



But if I use this in mql4 I get clrAqua (light blue):

Comment("Clr-Schemes: "+ColorToString(0xFFFF00,true)+"\n")



Of course the displayed objects are in clrAqua but not yellow?

Does anybody know what's going wrong?

 

According to the documentation on ColorToString(), the first parameter is not an integer value, but instead a colour constant in the format C'rrr,ggg,bbb'.

If you use a integer value instead, it will probably get interpreted as some non-documented internal format that might have has a different order such as BGR, thus causing it to be Cyan(Aqua) instead of Yellow.

In order to figure out the undocumented internal format, you will probably have to try out various values (0xFF, 0xFF00, 0xFF0000, 0xFF000000) to see how it is formed.

Followup: Just did some tests with the example code of the ColorToARGB() function and the results were as follows:

2016.10.26 15:59:37.922 testcolor EURUSD.m,H1: 0x55FF0000 - clrRed ARGB with alfa=0x55 (transparency 21.6%)
2016.10.26 15:59:37.922 testcolor EURUSD.m,H1: 0x000000FF - clrRed
2016.10.26 15:59:37.922 testcolor EURUSD.m,H1: 0x55008000 - clrGreen ARGB with alfa=0x55 (transparency 21.6%)
2016.10.26 15:59:37.922 testcolor EURUSD.m,H1: 0x00008000 - clrGreen
2016.10.26 15:59:37.922 testcolor EURUSD.m,H1: 0x550000FF - clrBlue ARGB with alfa=0x55 (transparency 21.6%)
2016.10.26 15:59:37.922 testcolor EURUSD.m,H1: 0x00FF0000 - clrBlue    
This shows that when an alpha is not used, the internal format (unit) is reversed as 0xBBGGRR, but when an alpha is used then the format is 0xAARRGGBB. Talk about twisted internals adopted by the MQL developers.
 

it is color type, hex is 0x00BBGGRR

best regards 

 
Demos: it is color type, hex is 0x00BBGGRR, or plain 0xBBGGRR

Is that a question or a statement?

If a question, then 0x00BBGGRR is the same 0xBBGGRR. The zeros on the left have no significance - hence 0x00000001 is the same as 0x1.

OK! I now understand that it was a statement and that you were quoting from the documentation, namely Color Type which states and I quote:

Integer-valued representation is written in a form of hexadecimal or a decimal number. A hexadecimal number looks like 0x00BBGGRR, where RR is the rate of the red color component, GG - of the green one, and BB - of the blue one. Decimal constants are not directly reflected in the RGB. They represent a decimal value of the hexadecimal integer representation.

 
In the doc of ColorToString() you can read only about

"R,G,B" in this sequence(!).

This is the same as FF FF 00 blue is at the end.

The color type tells you:

//--- Integral representations 
0xFFFFFF          // White 
16777215          // White 
0x008000          // Green 
32768             // Green

So in total it seems to be a bug - or is hex code read from the back?


PS: I hate isolated solutions. :(

 
gooly:
In the doc of ColorToString() you can read only about

"R,G,B" in this sequence(!).

This is the same as FF FF 00 blue is at the end.

The color type tells you:

So in total it seems to be a bug - or is hex code read from the back?

In the documentation, the "R,G,B" is in reference to the "string" results of the function or of the colour constant in string format C'R,G,B'. It is not in reference to the internal structure.

It is not a documentation bug, but I do agree that the internal "uint" storage of the color is "weird", but not a bug. As stated in my previous posts, the internal format is 0xBBGGRR (if not using an alpha component).

 
guys, it is in the docs , have a look at color type
 
Demos:
guys, it is in the docs , have a look at color type
Yes, I misunderstood your initial post, and have corrected my reply to it and supplied the documentation link and quoted the paragraph in question! Thanks!
New comment