- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
You could always implement a long-term corporate strategy:
"Any color you like, as long as it's purple."
Admin
Fixed?
Admin
I'm going to bet that version 1 of this whole thing was pre .NET.
Then one or both ends were ported to .NET separately and what we are seeing is nothing but homebrew "wire serialization" from an era when homebrew was the only kind there was. The shame is back then they could have done both ends together more smartly. Instead they just left this to fester, and because of copypasta, to proliferate.
I especially like that "unrecognized" maps to white on the server and to purple on the client. That's in addition to the gaps between their two mostly-overlapping sets of recognized colors.
I bet a truly diligent search of the codebase would find a few (a lot?) of different versions of each, with slightly different color gamuts in each. Such fun.
Admin
So, the first oddity is that the colo(u)rs are BGR, rather than the more typical RGB.
Then there's the fact that "Light Gray" is darker than "Dark Gray".
Then there's the question as to why the GetColor function starts to be concerned with 32-bit values rather than 24 bit values (e.g. 0x80_00_00_0F). [N.B. Underscores simply added to clarify the number of specified bytes.]
Then there's Light Gray being 2 different colo(u)r code - 0x80_00_00_0F (hex or -2147483633), or 0x80_80_80. Also, Orange is both 0x80C0FF and 0xFFFF (i.e. 65535).
Also, what is with the trailing ampersand on some of the hex values?
And this is ignoring the issue that these values are all strings, rather than numbers.
Admin
Forgive me, but I'm a bit slow in understanding why this is a WTF. The codes seem to correspond to each other, so that can't be it Or is the WTF that - for example - value 256 is used for red, when 256 is not the RGB code for red?
Admin
Once they are just treated as strings, the other oddities are just noise. 'Cept maybe two different values for Light Grey.
Admin
Return Color.Orange Return Color.Orange 'bright yellow
Admin
Those will be the windows system colours. For example &H80000005 is the window client background colour.
The format these numbers are in looks like VB6 hexadecimal, although I am sure there will be other versions of BASIC that do similar things.
Admin
The &H notation for hex values was present already in QBasic. It's quite possible that this tradition was kept in all following BASIC languages for PC?
Admin
The client doesn't look at numbers but strings.
Admin
What is not accounted for is that the original programmer(s) worked VERY fast, therefore they were impacted by relativity induced color shifts....
Admin
It only allows a very small set of colors. Any other color that you attempt to use will result in an error code and one of two default colors used.
The colors supported don't actually match completely. The client can interpret more color codes than the server will send.
It is passing the data using "numbers" - number as string.
All of the above problems could be fixed by using any one of the standard color encoding schemes. One library function call to encode the color and one library function call to decode the color. The in-house development team won't have to maintain those functions, they will work on both sides for all colors, and it will pass the data in a standardized format.