[Adding Max]
I saw this too. In button/style, you have to change
value="void 0"
to:
value="${void 0}"
Since those attributes are type color, they try to take their value as a
string, assuming a color name or CSS spec. We have to use ${} to pass an
expression.
I'm not sure what Max is trying to achieve here. Perhaps to silence any
warning if interior-border-color is not specified, and to signal that the
default color should be used instead? If that is the case, it might be better
to say:
value="${compute default color}"
?
On 2010-11-16, at 11:52, Captain Feng wrote:
> I tested both '0' and '.005', they worked well.
> Except one regression:
>
> Write a single <btn> test case, whether based on trunk or
> fredfeng-laszlochina:
> <btn name="viewasBtn" x="10" valign="middle" width="60" height="22"
> text="VIEW AS"/>
> Run the test case, got the following error from console:
> ERROR: Invalid CSS Color: 'void(0)'
> ERROR: Invalid CSS Color: 'void(0)'
>
> I don't know why....
>
> thanks,
> -Fred
>
> 2010/11/16 P T Withington <[email protected]>
>
>> On 2010-11-16, at 09:29, André Bargull wrote:
>>
>>>> static var PercentPattern = new
>> RegExp("^\\s*(1?\\d?\\d?\\.?\\d*)\\s*%\\s*$");
>>>> static var NumberPattern = new RegExp("^\\s*(\\d{0,3}\\.?\\d*)\\s*$");
>>>
>>> These patterns actually accept any number, because of the \\d*. And the
>> percent pattern also accept this string ".%" or simply "%".
>>>
>>> Percent pattern:
>> ^\\s*(100(?:\\.0*)?|\\d{1,2}(?:\\.\\d*)?|\\.\\d+)\\s*%\\s*$
>>> 1) "100", possibly followed by "." and any number of "0".
>>> 2) Any number in range [0,99], possibly followed by "." and any number of
>> "0". (This part allows leading "0", is that ok? For example "01%")
>>> 3) Or numbers without leading digits as in ".5%"
>>>
>>> A similar for the number pattern:
>> ^\\s*(\\d{1,3}(?:\\.\\d*)?|\\.\\d+)\\s*$
>>
>> Thanks. I rushed this out so Fred could proceed. Clearly it needs more
>> work.
>>
>> I don't know how rigorous we really have to be on the pattern. We could
>> just allow any number of digits before/after an optional `.` and then test
>> the output of parseFloat not being NaN.
>>
>> If we were using parseInt, a leading 0 could be a problem due to some
>> runtimes parsing that as octal.
>>
>
>
>
> --
> captain
