Just updated the code in the first post. It now checks to see if a color value is less than 0 but more than MIN_LONG, and if so, it converts it over to an INT64 value automagically. Some folks still use LONGs to hold their color values (even though I strongly discourage that, as it can cause issues with POINT and other intrinsic QB64 statements which use UNSIGNED LONG, FLOAT, or INTEGER64 values), so this checks for that now and converts up to INTEGER64 so that anytime someone gets a negative result, they know that ColorValue failed to produce a color properly from the string.
Also added in the _TRIM around the bushes, as Spriggsy was talking about, so leading or trailing spaces shouldn't be an issue any longer.
Also _TRIMed up the IsNum function, so that STR$(x) will now properly report that it's a number. (Remember, STR$(x) converts to add a space before our number, if it's positive, such as " 1". " 1" is not the same as "1", so it reported "Not a Number". That's been corrected.)
Added in an extra color value which somehow got removed from QB64's color list -- "Grey". We used to have both "Grey" and "Gray" as the exact same values, where one was basically American English spelling while the other was Goofy English spelling (you know British or Australian or Plutonium or such). I guess at some point, Fellippe and Luke decided on one official spelling for us and removed "Grey", leaving just "Gray", but I've added the color back into our ColorValue function for us.
If anyone has any other custom colors that they'd like to see supported, feel free to speak up and I'll happily add them. As you can see in the
code, it's structured with that entire purpose in mind, with none of the values hardcoded in anywhere. Just find the spot in the alphabet where your color goes, and pop it and its value right in there! It really is that simple!
Anyone with any other ideas for improvements, or who can see where there might be issues/glitches in the code, kindly speak up and let me know, and I'll happily address the issue.
