Call to all you one-liners !

[Mark Wieder]

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
 mwieder at ahsoftware.net