On 11/16/10 9:02 AM, P T Withington wrote:
[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?
That's exactly what I was trying to do.
If that is the case, it might be better to say:
value="${compute default color}"
?
Yeah, having an explicit sentinel value is probably better. Can you or
Fred file an improvement?
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
