[lmi] Census editor: floating-point values

[Greg Chicares]

Consider this example of editing a floating-point value:

  File | New | Census
  Census | Edit cell
    change "Retirement age" to 46  [on "Client" tab]
    change "Dumpin" to 1000000     [on "Payments" tab]
  OK

Now edit the "Dumpin" with the census editor. It displays "1e+006".
Elsewhere in lmi we strive to avoid scientific notation because end
users find it objectionable.

Click the top spinbutton once; it displays "1.00000e+006" (showing
five decimals, where previously there were none); but the first two
characters don't fit, so only "00000e+006" is visible. Click the
bottom spin button twice, and "999999" appears. Having worked with
functions like printf(), I'm not too surprised by this:
   999999  -->   "999999"
  1000000  -->        "1e+006"  [would be more than six digits]
  1000001  -->  "1.00000e+006"  [fractional part not exactly zero]
but our end users would be surprised, especially by the distinction
between the last two.

Using the spinbuttons as above, first change the value to "999999",
and left-click elsewhere in the dataview window's client area: the
change is accepted. Then change it to 1000001 and click elsewhere;
the value changes to 1000000, a different number.

Now try similar operations by typing digits instead of using the
spinbuttons; apparently no change is accepted. To reproduce:
delete "1e+006" and type "1234", then click elsewhere; the value
reverts to 1000000. This issue is specific to the spinctrls used
for floating point: edit "Retirement age", delete its contents,
type "90", and click elsewhere; this integer change is accepted.

Aside from these concerns, wouldn't textctrls seem more natural
for floating-point values? End users rarely want to change a value
of 1000000 to 1000001; they're likely to change 1000000 to 2500000.
I don't think the extra features of a spinctrl will prove useful.