These objects are not available for public use (you cannot construct one and use it), instead these objects are created by the input assist behaviors.
The following description provides an outline of how Number assist processes keystroke, mouse and clipboard interactions when it is applied to an input field containing a Number string.
When the field receives focus, the value is transformed to "input format", it is coerced to be a correct value and prompt characters replace leading and trailing zeroes, the result is displayed and the cursor is positioned before decimal point (or the implied decimal point).
The "input format" of a Number is constructed based on the Number's format. Essentially, all characters that are not # or 0 in the pattern are treated as literals and all # and 0 characters are marked as input capable positions. Thousands separators are maintained where needed (i.e., they are removed from between leading zeroes). The value is converted to the input format and coerced to be correct. Coercion forces the value to be within the bounds and forces the value to be non-null unless strict is set to 2 in the converter (if strict is set to 2, the value is left null).
For example, given the Number format of $ #,##0.00;($ #,##0.00) and the value -1, the result is ($ *,**1.**) if the prompt character is *.
When the field loses focus, prompt characters are removed from the field, the value is coerced to be a correct value (thus it is always 'correct' after onblur) and the value reformatted using its (original) format. "Coercion" in onBlur is the same as coercion in onfocus. Note that prompt characters are replaced with zero when they are removed (unless padding is turned on in which case they are replaced with the pad characters).
When a digit key is pressed (that is a keypress event is generated), the behavior is rather complicated depending on whether the cursor is to the left or the right of the decimal point. Basically to the left of the decimal point, typing is handled in "insert mode" that is, the character is inserted at the cursor position and digits to the left shift left one position. To the right of the decimal point, the cursor is in overstrike mode and replaces the character to the right. The goal is that someone can type "123.45" into an empty field (with the cursor initially at the decimal point) and the correct value is entered. Typing literal characters such as the decimal point and thousands separator "hops" over the next such character. Typing to the left of the value, zero-fills the value from the cursor to the first significant digit. In all cases, if an invalid key is pressed, "nothing happens". If the number would "overflow" (too many digits entered), "nothing happens" when the extra characters are typed.
Because a number pattern does not describe which characters are the actual "sign" characters in the number (many characters in the pattern may be used to indicate the value is signed, e.g., leading and trailing parentheses), pressing the plus or minus key anywhere in the number toggles the number's sign. Special handling of the sign occurs when parts or all of the value are deleted. Again, the goal is to make typing something like -100.00 into an empty number work correctly.
When a control key is pressed (that is a keydown event is generated with a control key indicated in the keycode), NumberAssist processes the control key on the keydown event (this is the norm in Windows®). If the control key is a right or left arrow, the cursor is advanced/regressed to the next position in the string where input can occur. If the Del key is pressed, the character after the cursor position is deleted (or the selection if one is present), and the cursor advanced. If the backpace key is pressed, the character before the cursor position is deleted and the cursor moved back. Deleting a selection that spans the decimal point requires special handling to adjust the value and as a rule the cursor is positioned just before the decimal point. If tab or enter are pressed, the normal form processing actions are taken. No other control keys are processed specially (e.g., HOME and END are not processed specially but they work as expected.
Customer requirements (vocally expressed) require that thousands separators be dynamically added/removed as need be as the user types (adds or removes one or more characters.
If the user clicks in the field (and the click is not part of a selection), the cursor is positioned before the "next" character where a user may type.
Cut/Copy/Paste interactions are only handled in IE (Mozilla does not support this) and only limited support can be provided in IE (while it provides a full set of events for managing interactions, IE has only limited access to the clipboard itself which restricts what can be done).
Copy copies the selection to the clipboard verbatim. Cut does the same except it clears the selection (sets all input positions to blank). On a paste, if it appears that the value on the clipboard was a Numbered string, the "input" characters (non-literal) characters only are pasted otherwise the entire string is pasted. The paste applies characters only to "input" positions (skips literals). If any character fails input validation, the entire paste is cancelled otherwise the cursor is put at the end of the pasted characters (though the browser sometimes then moves the cursor position).