Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Bug in RGB() function
Message
De
26/06/2015 13:42:07
 
 
À
26/06/2015 05:28:14
Lutz Scheffler
Lutz Scheffler Software Ingenieurbüro
Dresden, Allemagne
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Versions des environnements
Visual FoxPro:
VFP 9 SP2
OS:
Windows Server 2012
Network:
Windows 2008 Server
Database:
MS SQL Server
Application:
Web
Divers
Thread ID:
01621469
Message ID:
01621490
Vues:
75
My (incorrect) assumptions were based on :
1. In the world today color numbers are standardized
2. The docs say as you quote, but if you read further it gives an example of setting blue using RGB(0,0,255). Implies normal order, not BGR order.
3. Nowhere does it mention in the docs the critical point that the RGB function returns BGR order, a pretty big omission. In fact all the docs seem to imply all numbers will be in RGB order.

After all these years, it just goes to show there is always something new to learn.

>Whats the real problem?
>VFP (no idea how far back but possible Fox as well) uses the BGR numbers for colors. For convinience RGB() was added, but not a single line states that the return of RGB() is in any order. Thats (your) pure assumption.
>Help says: Returns a single color value from a set of red, green, and blue color components. and The value returned by RGB( ) can be used to set color properties such as BackColor and ForeColor.
>Where do you see a something that gives an order or a construction rule?
>
>If you look into the examples given by, lets say HELP BACKCOLOR, you will see the numbers as they are.
>
>There is no excaption for the use of the color value anywhere in VFP, so there is no problem too.
>
>If you need an explanation learn about byte order aka endianness. There is some C that runs the VFP code and in the days of yore a developer has decided to use it in that order. While it is no issue to a VFP developer to concenate the number the one or the other way, it might have been a big deal to rework every number sometimes. But possibly M$ decides to change it in the next version. :)
>
>>if the decimal number returned by RGB() is using the parameters in backwards order, that is a major bug that contradicts all the VFP docs and common sense. It also is internally contradictory. Using the RGB() function to set a color property works exactly as the docs say and as one would assume - R then G then B. But the RGB() functon returns a completely different number when used not to set a property but as a function to return a value.
>>
>>IOW .backcolor=rgb(204,198,149) shows the correct color. And it returns the correct value. But the function RGB() when used by itself returns a number based on backwards BGR order. That is beyond inexplicable. VFP is really using BGR but internally converts everything in a color property to RGB?
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform