Re: [lmi] Input-sequence editor integration

[Greg Chicares]

20100703T1542Z (revision 5020): nothing to say.

20100703T2251Z (revision 5021)

'mec_input.hpp' has input sequences, but they're numeric-only, so the
payment and mode types don't need reconstitutors here.

I think the following code, just now moved into 'datum_sequence.cpp', can
be combined with other things just moved into 'input_harmonization.cpp':

    bool payment_indeterminate =
        (
        false
    // TODO ?? Further conditions to disallow improper input:
    // need to compare corresponding years.
    //  || specamt strategy is neither 'none' nor 'salary-based'
        );

    if(payment_indeterminate)
        {
        permissible_keywords.clear();
        }

The hardest part of this changeset by far was 'input_harmonization.cpp'
from my POV, even though it's a trivial and correct refactoring. Except
for spacing, it's only this:

http://svn.savannah.gnu.org/viewvc/lmi/trunk/input_harmonization.cpp?root=lmi&r1=4973&r2=5021&diff_format=u

     Payment           .enable              (mce_solve_ee_prem != SolveType);
+    Payment           .block_keyword_values(mce_solve_ee_prem == SolveType);
     CorporationPayment.enable              (mce_solve_er_prem != SolveType);
+    CorporationPayment.block_keyword_values(mce_solve_er_prem == SolveType);

but I had no less than three successive epiphanies (so you know two of
them must be wrong) wrt the two lines that were essentially moved here
from elsewhere:

(1) They NEED NOT be written. They just block keywords when the control is
disabled, and you can't type a keyword or anything else into a disabled
control. The refactoring has served to make this apparent.

(2) They MUST be written. A nasty shortcoming of our pre-wx legacy system
was that it validated input only within the GUI, but it's common to produce
illustrations--e.g., for every cell in a census--without even opening the
tabbed dialog. The MVC framework in lmi makes it easier to avoid bypassing
validation (which resides in the Model...which is independent of the GUI),
but doesn't guarantee success. Thus, the refactoring seemed to have removed
an instance of that error.

(3) They MUST NOT be written. I realized this when I decided I couldn't
accept (2) without proving it, and instead proved the opposite:

  File | New | Illustration
  "Corporation payment": type 'gsp;0'
  "Solve for": choose "Employer premium"
  OK

Choosing the solve makes the payment sequence irrelevant; it shouldn't
be revalidated in a keywords-forbidden context. However:

  Input validation problems for '':
  Expected number. Current token 'keyword' at position 3.

That's reproducible with binaries from years ago. The refactoring has
exposed a latent defect. At any rate, refactoring for simplicity is a
Good Thing.