![]() |
suggestion for Color, $COLOR:0, $COLOR:32 pages - Printable Version +- QB64 Phoenix Edition (https://qb64phoenix.com/forum) +-- Forum: Chatting and Socializing (https://qb64phoenix.com/forum/forumdisplay.php?fid=11) +--- Forum: General Discussion (https://qb64phoenix.com/forum/forumdisplay.php?fid=2) +---- Forum: Wiki Discussion (https://qb64phoenix.com/forum/forumdisplay.php?fid=25) +---- Thread: suggestion for Color, $COLOR:0, $COLOR:32 pages (/showthread.php?tid=3656) Pages:
1
2
|
suggestion for Color, $COLOR:0, $COLOR:32 pages - madscijr - 05-01-2025 In the past few months I noticed programs using actual color names in the color statements, I guess these were added to QB64PE somewhere along the way? This is great since I can eliminate those color name functions I'd been using! I googled QB64PE color names and found them documented at $COLOR:0 $COLOR:32 however there wasn't any example or explanation that to get them to work you have to use the command e.g., $COLOR:0 Also the entry for Color in the wiki doesn't really mention them or have any examples with them. $COLOR:0 and $COLOR:32 are in the "see also" list at the bottom, but it's kind of left to the reader to figure that out. I would suggest adding them to the examples and/or explanation of those pages... Code: (Select All) ' $COLOR:0 Name Table RE: suggestion for Color, $COLOR:0, $COLOR:32 pages - SMcNeill - 05-01-2025 You missed their entry in the wiki apparently: https://qb64phoenix.com/qb64wiki/index.php/$COLOR RE: suggestion for Color, $COLOR:0, $COLOR:32 pages - RhoSigma - 05-01-2025 And the $COLOR meta-command is mentioned 1st in the "See also" section of the COLOR page. RE: suggestion for Color, $COLOR:0, $COLOR:32 pages - madscijr - 05-01-2025 Yes, but I would argue that including an example on the page for Color would be helpful, since it directly relates to that command... RE: suggestion for Color, $COLOR:0, $COLOR:32 pages - RhoSigma - 05-01-2025 (05-01-2025, 08:13 PM)madscijr Wrote: Yes, but I would argue that including an example on the page for Color would be helpful, since it directly relates to that command... Rather no, it does not directly relate to COLOR, it's an far later convenience feature added with the $COLOR meta-command (and there are the examples), but as it indirectly relates to the legacy COLOR command, as it makes things easier, it's also added to the "See also" section of COLOR. The real problem I see here is that people doesn't take the time to read a wiki page carefully from top 'til bottom and by that they are missing the essential bits of information they really look for. I already thought about reformatting all wiki pages placing the "See also" section at the top. RE: suggestion for Color, $COLOR:0, $COLOR:32 pages - madscijr - 05-01-2025 That sounds like someone more interested in being semantically correct but missing the bigger point - good documentation makes it EASY for the reader. I think if we have a Color command that accepts color values, and there is a way to use the color word instead of a number, it is perfectly logical and helpful to have that information on the Color command's page. Why would a person click "see also" on Color$ when that link doesn't indicate anything about what it's for? Like maybe it could say, "Click here to learn about how to use the word Red for this command instead of the number 4"? Many "see also" links are useful, but if the reader is trying trying to zero in on specific information, they might not think to miander around and do a depth-first read of everything. To help, you put in a little more description. RE: suggestion for Color, $COLOR:0, $COLOR:32 pages - SMcNeill - 05-01-2025 Honestly, in my opinion, the COLOR page should be purged of most of the junk on it on. MY idea color page? Quote:COLOR can be used to set the Foreground and Background colors. That's it. All the junk about Screen Mode Attributes should go to its own page. Read & write color port intensities with INP & OUT... is again, NOT really about COLOR at all but about one use for INP and OUT. Those should be gone, with nothing more than a link referring to them on their own respective page. Example 1 on the page... DOESN'T EVEN HAVE THE COLOR command in it! WTF is it there?? Example 1: Reading the default RGB color settings of color attribute 15. Same with Example 2. As for $COLOR, it needs to stay on its own separate page as well. There's just too much info jumbled onto the page that has nothing to do with the command itself. Why document COLOR Red to be red with $COLOR:32, and then not bother to document: COLOR 4 is RED in SCREEN 0 COLOR 40 is RED in SCREEN 12 COLOR _RGB32(255, 0, 0) is RED in 32-bit SCREENS. COLOR _RGB(255, 0, 0) is the closest approximation to red in any screen mode that has red in its palette. COLOR Red is Red in SCREEN 0 *IF* $COLOR:0 is set, and is Red in 32-bit screens *IF* $COLOR:32 is set, otherwise it defaults to color 0... And, of course, one would have to do that same breakdown for every color and every value and... /gah!! And none of that has to do with the simpleness of what color actually does!! Quote:COLOR can be used to set the Foreground and Background colors. That's basically all that page needs to tell you. The rest is just SEE ALSO. Folks miss the really important stuff because it just gets buried beneath all the other crap. ![]() Also, see the highlighted version of the text above. $COLOR is mentioned right there in the Description, along with what it does. What more info does one need to realize, "Hey, I can use named colors with $COLOR"? RE: suggestion for Color, $COLOR:0, $COLOR:32 pages - RhoSigma - 05-01-2025 Being systematicly, guilty your honor ![]() Let's say I place a simple example on the COLOR page, eg: COLOR White, Red PRINT "this is white text on red background" now someone like you comes and thinks oh cool, I didn't know this works, I'll copy the example and paste it in the IDE to try it out. But what, I only get a black screen, not even the "Press any key..." to end the program is there, does it hang. No, White and Red are not defined, hence 0. So it sets COLOR 0,0 and prints the text. You need the $COLOR:0|32 first, so that the color names get included and defined. Now indeed, I certainly would include the $COLOR:0 in the beginning of my example, so it works. But now an unexperienced user wouldn't get the connection between the $COLOR metacommand and the color names, but would likely think he always needs to include the $COLOR in the beginning so he's able to use the COLOR command (like a main switch), but that's not true either. COLOR works without the $COLOR metacommand. Doesn't matter of your POV, the COLOR command and the $COLOR metacommand serve two totally different purposes. One does actually set the colors in your program and the other just defines some named color CONSTs for your convenience, which you also could do yourself. As a convenience addition $COLOR is mentioned several times on the COLOR page, but the examples regarding the use of the color names definitly belong to the $COLOR metacommand page, because only with that metacommand in effect COLOR White, Red works. RE: suggestion for Color, $COLOR:0, $COLOR:32 pages - PhilOfPerth - 05-01-2025 (05-01-2025, 10:31 PM)RhoSigma Wrote: Being systematicly, guilty your honor Probably over-simplistic, but for my progs, I just add 3 or 4 Subs that define the colours I want to use: Sub Red: Color _rgb(255,0,0) End Sub Then, in the prog I just write Red: Print? "This is red" Works for me! ![]() RE: suggestion for Color, $COLOR:0, $COLOR:32 pages - madscijr - 05-01-2025 All good points, I think removing extra stuff is fine, and putting the $color on its own page is fine, just as long as it's linked to with some context to give the reader a clue for what it's for. Microsoft's docs do that pretty well, like if a function accepts a parameter that has enumerated values, they say the name so you can go to the enumeration page and see what all the possible values are. |