RGB values with/without leading 0x

[jeeswg]

- In various places you can specify colours either as ABCDEF or 0xABCDEF, causing confusion. E.g. GUI objects, PixelSearch, Progress, SplashImage.
- I would suggest to make 0xABCDEF the default everywhere. Advantages are that you can: omit double quotes, specify transparency, specify decimal integers, avoid fiddly conversions (dec to hex, then crop '0x').
- (Also re. colours, PixelGetColor/PixelSearch have BGR options in AHK v1, which might be useful to have in AHK v2. One reason is that if an AHK v1 script used the BGR mode, that bit of code cannot be easily converted at present.)
- Thanks for reading.

[nnnik]

I think making ARGB in 32 bit the standard color format should be OK.
The downside is that you always need to specify alpha channel. e.g. 0xFFFFFF would be invisible due to the missing alpha channel and is equivalent to 0.

[Helgef]

In general, +1 for using pure numbers over numeric strings.

Cheers.

[jeeswg]

- Yes, basically forget about the alpha channel, unless someone wants it. Assume that only the RGB values are considered, and that the A value is ignored (assumed to be 0xFF).
- Points like this re. RGB values may seem subtle, however, sometimes I base my functions on AutoHotkey commands/functions, then I realise I should have done things slightly differently, and I end up rewriting my functions and editing all instances of them.

[nnnik]

- Yes, basically forget about the alpha channel, unless someone wants it. Assume that only the RGB values are considered, and that the A value is ignored (assumed to be 0xFF).

You say yes but my message actually said the opposite.

Some functions require the alpha channel or could use it to replace other parameters - e.g. search for a partly transparent color instead of searching for a color with variation.
Specifiying a control or drawing color the alpha channel is the same. Essentially all drawing APIs use the Aplha channel. This could cause issues and strange inconsistencies with other functionality.
But of course that inconsistency is not horrible and it might be simple to overlook it for practical purposes.

Reading through MSDN it seemed to me that only 0 is considered completely transparent meaning that 0x00 00 00 00 is completely see through.
0xFF 00 00 which is essentially the same as 0x00 FF 00 00 would be interpreted as 0xFF FF 00 00 ( red ) instead since it is not completely 0.
The only case which isn't covered by this is black since it is 0x00 00 00 which is exactly the same as 0 which is completely transparent.
This means in order for 0 to be black it needs to be written as 0xFF 00 00 00

Another option I see would be the simple inversion of the alpha channel. 0x00 FF FF FF would be white and completely intransparent. 0xFF FF FF FF would be completely transparent.
This is also kinda strange since I have never seen this before and goes against the common convention. - ( Yet it's an easy solution for this problem ( why has nobody thought of this when making this ) )

The last option I see is to always fully define the Aplha channel.

[jeeswg]

Yes, good points. I realised exactly that when thinking it over, whoever designed ARGB, for A we have 0xFF as opaque, and 0x00 as completely see-through, the opposite might make more sense, but as you say it's probably best that we don't go against the convention. So, *an* alternative could be a space-separated list with A or T to indicate transparency where needed.