Allow input of full floating point numbers with exponents such as "1.345e+5"

[grumpyinca]

Allow input of full floating point numbers with exponents such as "1.345e+5" into the entry fields of the main web page.

Issue #11 was broken apart. This portion is considered lower priority.

[grumpyinca]

Note that this issue is also related to difficulties in entering negative numbers in the entry fields on the main page.

[grumpyinca]

It is possible that changes for this issue could be combined with changes for issue #131.

[grumpyinca]

Per today's discussion, this issue should be moved to milestone 4.1 so that its resolution can supply infrastructure for code in branch #590.

The resolution to this issue should include:

• Ability to enter numbers in scientific notation
• Ability to enter values less than 1.0 with a leading decimal point as opposed to a leading zero.
• Ability to enter negative values with a leading minus sign.

[1fifoto]

Changed all numeric input fields, that is, Independent variable numeric values, min constraints, and max constraints; Dependent min constraints, and max constraints; and Calculation input numeric values.

[grumpyinca]

Revisit File : Preferences to disable the "Apply and Close" button if any input value is invalid. Write a "disabled =" clause for the "Apply and Close" button.

[1fifoto]

Also added border-invalid to all NaN parsed numeric strings

[grumpyinca]

Just for the record ... With the current state of the input checking code, it is possible to continue from those places where the numeric validity testing disables an associated button by clicking outside the dialog (or Advanced View cell). File : Preferences is most robust because no partial or invalid values can be applied because the "Apply and Close" button is disabled. The previous (last known good) value will persist. Advanced View, the Calculator View Value Input dialog (SymbolValue), FDCL dialog and Trade dialog(s) are somewhat less robust because it is possible to enter an initially valid fragment (for example: "1") that changes the model but later invalid / incomplete input (for example: "1e") happens. In this situation, the model is not returned to the last known good value when the click outside the dialog happens. The initially valid but possibly incomplete input persists.

This behavior is considered acceptable for release in v4.0.7. If desired, improvements can be made in a future release.

[grumpyinca]

Merged to master; pushed to remote. Closing.

[grumpyinca]

Testing has established that attempting to open a torsion spring design fails with the message:

TypeError: _this.props.element.value.toODOPPrecision is not a function
new NameValueUnitsRowCalcInput
C:/Users/Mike/git/odop/client/src/components/NameValueUnitsRowCalcInput.js:39
  36 | //            console.log('In NameValueUnitsRowCalcInput.constructor table=',table);
  37 |             this.state = {
  38 |                 table: table,
> 39 |                 valueString: this.props.element.value.toODOPPrecision(), // Update the display
  40 |                 focused: false,
  41 |             };
  42 |         } else {

It is obvious that line 39 is in a section that deals with Calc Input entries of type table. On comparing with NameValueUnitsRowIndependentVariable.js, I was not able to see any differences in the definition of ODOPPrecision.

I was able to determine that the table triggering the error seems to be heattreat.json which does not appear in the other spring types. heattreat.json contains only (non-numeric) string values. However, that aspect is not unique. The Life_Category and End_Type tables for all spring types are similarly non-numeric.

[1fifoto]

Change table code to treat 'value' as a string by using the toString() function instead of toODOPPrecision() which is only available for number types. Check into branch 31.