Ken- Sunday, June 27, 2010, 12:16:21 PM, you wrote:
> Well that's where you and I differ - if I accidentally passed "2555" instead > of "255" for one of the integers in a color value, I'd want to be told that > that's an error. This is especially true when the docs for all the color > tokens state "The RGBColor consists of three comma-separated integers > between zero and 255..." So if it's either not an integer or outside that > range, I'd assume I'd receive an error. The docs are somewhat correct: if you request the (back)color property of an object after setting its (back)color to values that are outside the "normal" range (1000,1000,1000, for example) then you'll receive the integer values mod 255. So if you *get* an RGBColor the values will be indeed in that range. > So in my eyes, this is a bug in the "is a color" function. BTW: This is > along with the already existing bug with the function that returns true if > you just pass a zero to it. And similarly, you can set the backcolor (or any > other color property) of an object to 0 and not get an error... Depends on your objective. If the aim of the "isAColor" function is to determine whether the passed parameter can be used as a parameter in setting one of the color properties, then I think the function performs as designed. This seems to me to have more useful applications than the goal of determining whether the parameter is a comma-separated three-item string of integers between 0 and 255. OTOH, you may have a need to determine exactly that, in which case your regex solution would fit the need quite well. -- -Mark Wieder [email protected] _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
