NumberTextBox {places:'0,3'} does not format with maxPlaces onBlur

[GreenGoblin]

When specifying a range of decimal places for NumberTextBox? such as {places:'0,3'}, editing allows the correct range of decimal places but the field is not formatted with 3 decimal places when tabbing out of field.

As specified in the documentation:
To specify a field where 0 to 3 decimal places are allowed on input,
but after the field is blurred the value is displayed with 3 decimal places:
|{places:'0,3'}

A simple example:
<input dojoType="dijit.form.NumberTextBox?" id="testPlaces" name="testPlaces" constraints="{places:'0,3'}">

[bill]

Sounds like a bug, or at least we need an update to the doc...

[Douglas Hays]

#10669 changed this behavior in dojo core

[GreenGoblin]

The issue is in dojo.number (dojo/number.js)

The comments indicate that a places range "n,m" will format to m places:

dojo.number.__FormatAbsoluteOptions
	//	places: Number?|String?
	//		number of decimal places.  the range "n,m" will format to m places.

The relevant code is in dojo.number._formatAbsolute on lines 197-215

	var valueParts = String(Math.abs(value)).split("."),
		fractional = valueParts[1] || "";
	if(patternParts[1] || options.places){
		if(comma){
			options.places = options.places.substring(0, comma);
		}
		// Pad fractional with trailing zeros
		var pad = options.places !== undefined ? options.places : (patternParts[1] && patternParts[1].lastIndexOf("0") + 1);
		if(pad > fractional.length){
			valueParts[1] = dojo.string.pad(fractional, pad, '0', true);
		}

		// Truncate fractional
		if(maxPlaces < fractional.length){
			valueParts[1] = fractional.substr(0, maxPlaces);
		}
	}else{
		if(valueParts[1]){ valueParts.pop(); }
	}

The calculation of maxPlaces is already done above this section so changing to the following seems appropriate and works properly in my testing:

	var valueParts = String(Math.abs(value)).split("."),
		fractional = valueParts[1] || "";
	if(maxPlaces){
		// Pad fractional with trailing zeros
		if(maxPlaces > fractional.length){
			valueParts[1] = dojo.string.pad(fractional, maxPlaces, '0', true);
		}

		// Truncate fractional
		if(maxPlaces < fractional.length){
			valueParts[1] = fractional.substr(0, maxPlaces);
		}
	}else{
		if(valueParts[1]){ valueParts.pop(); }
	}

[Douglas Hays]

patch to trunk to make parse aware of editOptions

[Douglas Hays]

Please review the attached patch. In the referenced example, the NumberTextBox? widget instance now needs editOptions:{places:"0,3"} and constraints:{places:3} if you want the old behavior.

[GreenGoblin]

This looks like it should address the issue although I was a little surprised that you really did change the documentation. Does this mean you are going to change the documentation for dojo.number as well?

I would like to test and use these changes, so:

I am using the Google 1.5 CDN. Is there a CDN to access this trunk for testing? Is this change going to appear soon (1.5.1 instead of 1.6)? Is it possible for me to make a local change to NumberTextBox? or dojo.number and be able to integrate this with the CDN or is the only option to switch to full local source? I could not find a way using modulePaths to load dojo.number locally which would be useful until the change comes out.

Thank you

[Douglas Hays]

(In [23070]) Fixes #11889. Make parse::NumberTextBox? and _setBlurValue::NumberTextBox? aware of editOptions that are in effect while the textbox has focus. Added additional automated tests (file renamed to robot/ValidationTextBox.html).

[Douglas Hays]

Should be able to continue using the 1.5 CDN and locally extend NumberTextBox? with just these changes.

[GreenGoblin]

Thank you, I did make a modified local version of NumberTextBox? with the changes and it works as specified. I was mainly having trouble trying to see if I could have a substitute dojo.number module while using a CDN. I could not come up with an easy answer but the final solution involved NumberTextBox? which was workable.

At this point, the dojo.number will need the documentation changed as well. Should I submit that as a new issue?

[Douglas Hays]

dojo.number doc change should occur as part of #10669

[bill]

Starting with [23070] I'm getting 6 failures on ValidationTextBox?.html on chrome (windows and mac). It's passing on FF3.6/win. test_validate.html passes on [23069] on chrome.

[Douglas Hays]

(In [23238]) Fixes #11889. doh.register test names cannot be numbers (as strings) since these get added as array indexes and are processed before other object members, out-of-order in Chrome.

[bill]

In [30579]:

Use lang.delegate() rather than lang.mixin(), both for efficiency and to avoid spuriously triggering custom getters in "this". Refs #10362, #11889, #16693 !strict.

[bill]

updated test case, type 1.3 in the first field and tab away, it will change to 1.300