dijit.NumberTextBox (and related) do use editOptions pattern with custom pattern in constraints

[Phil DeJarnett]

Due to this line (line 93):

constraints = dojo.mixin(dojo.mixin({}, this.editOptions), constraints);

If a custom pattern is supplied (say, to allow -$1.00 or 00051 formatted values), the edit pattern never gets applied, and it becomes difficult to edit other formats.

I believe the line should be modified, to give editOptions preference over constraints (so a user can still override editOptions.pattern is necessary):

constraints = dojo.mixin({}, constraints, this.editOptions);

Also, as above, there is no reason to call mixin multiple times, as it handles multiple arguments.

[Douglas Hays]

(In [19941]) Fixes #9671, #9729. Changed constraints mixin to add editOptions last. Added test for editOptions to test_validate.html. Add specialized isValid to NumberTextBox? to return the correct isValid when editing and the displayed value has not yet been formatted. This happens when ENTER is pressed inside a Form widget. Fixed an automated test oops.

[bill]

[19941] breaks Spinner_mouse.html, specifically that typing "0.5" into the first spinner is no longer flagged as an error (it doesn't turn yellow).

The first spinner has constraints:

<input dojoType="dijit.form.NumberSpinner"
	...
	constraints="{max:1550,places:0}"

[bill]

Oops, in [20441] I just changed the Spinner_mouse.html test to type "0.a" rather than "0.5", thinking that the latter *wasn't* invalid. Please change it back after fixing this.

[haysmark]

Fixes #9671. isValid now checks with parse to determine whether the user's partial input is valid. _getValueAttr uses more strict detection of exponential values.

[haysmark]

I attached a potential fix.

[Douglas Hays]

(In [20515]) Fixes #9671. Call parse to detect invalid fractional values. Check for exponential notation that is erroneously rejected by parse. Allow HOME and END to edit invalid values. Added several automated Spinner tests.

[Adam Peller]

(In [20555]) replace eval with Math expression from [20515]. Refs #9671