Re: [lmi] System crashes with invalid input using input sequence GUI

[Greg Chicares]

[...trying to make sure deferred issues haven't been forgotten...]

On 2015-05-20 23:31, Vadim Zeitlin wrote:
> On Wed, 20 May 2015 14:47:33 +0000 "Boutin, Wendy" <address@hidden> wrote:
> 
> BW> File | New | Illustration
> BW> Payments tab
> BW> Select ellipsis for 'Individual payment'
> BW> Change 'until maturity' to 'until age'
> BW> Select 'Add' button
> BW> 
> BW> There is clearly an input validation error occurring,
> BW> but the system crashes when the diagnostic appears.
> 
>  I did end up by modifying wxWidgets to make sure such crashes do not
> happen in the future, see commit[1].

We updated wx in August. Now I don't observe a crash.

> However lmi UI still behaves
> surprisingly (at least I personally find the behaviour described in [2]
[ 
https://github.com/wxWidgets/wxWidgets/commit/ba107a9a873abf7fefe003ef370e0f3c8c9239aa
 ]
> quite unusual) even with that fix and I think this really needs to be fixed
> at lmi level instead

Following those steps with lmi HEAD now, here's what I see. A new row
is added in the middle of the dialog:
  20000 from age 99 for a period of 0 years
Below the bottom row this message appears:
  Interval [54, 54) is improper: it ends before it begins. ...
and the "OK" button is disabled.

The value in that spin control
  for a period of 0 years
                  ^
can be changed from 0 to 1. But if I change it to 1 and then tab away, it
changes back to 0. AIUI, that's the anomaly that the lmi patch would fix,
by graying the spin control and freezing its value at zero.

I would say that the real defect is that the "Add" button was enabled at
all, when clicking it produces these necessary consequences:
  (a) an invalid interval,
  (b) an error message to that effect, and
  (c) a disabled "OK" button;
and, incidentally, another consequence that could be avoided:
  (d) the weird spin control symptoms described above,
which formerly led to:
  (e) a crash, which has now been prevented by a wx update.
I don't think it's worth eighteen lines of code to avoid (d) now. Either
we attack the root cause, or we decide to live with a set of anomalies;
and in terms of severity d is probably what would bother end users least,
so they won't see a+b+c+d as noticeably worse that a+b+c.

> BW> It'd be cleaner if it behaved similar to:
> BW> 
> BW>   File | New | Illustration
> BW>   Payments tab  Select ellipsis for 'Individual payment'
> BW> - Change 'until maturity' to 'until age'
> BW> + Change 'until maturity' to 'until retirement'
> BW>   Select 'Add' button
> 
>  The trouble is that adding a new row when the first row contains "until
> age 99", which is the maximal allowed age here, apparently, results in a
> negative range of possible values for the spin control in the new row. This

Agreed.

> doesn't happen in the "until retirement" case, as there are still 34

Yes. Of course, at the first step
  Change 'until maturity' to 'until age'
we could pick a different until_age than 99, but I see no other choice
that would really be any better. E.g., suppose we pick the retirement
age, which is often some recognizable round number like 65. But often
enough it has some other value--say, 57--which the end user may have
entered and forgotten. If 57 pops up here, that's surprising. Moreover,
retirement age can also be 99, which elicits the problem we had hoped
to solve; and of course if they want to use retirement age, that's one
of the options provided.

The problem isn't where we cut the interval into two nonempty pieces.
The problem is that we then offer to divide an indivisible piece.

> A possible alternative would be to disable the "Add"
> button if there are no valid values for the controls in a new row, but this
> wouldn't could be quite confusing as nothing would indicate to the user
> that the age must be reduced in order to allow a new row to be added.

Let's take a moment to think this through carefully.

When the ellipsis is clicked, we see a single row:
  20000 from issue date until maturity
There's no "Add" button because that interval is plenary and there's nothing
to add. The "until maturity" control can be changed, e.g., to "until age";
we have to allow that, because otherwise there's no way for the user ever
to change the sequence. So far, everything seems correct.

Now change the endpoint to "until age". A limiting age of 99 appears:
  20000 from issue date until age 99, then   [Remove]  [Add]
                                              ^^^^^^^^^^^^^ both enabled
  0 from age 99 until maturity
This is where the problem arises; but what is actually wrong here?

The underlying sequence is fine: 20000 every year, but 0 in the last.
The user wanted to add an interval, so...
 - the only reasonable default payment in the new interval is 0;
 - there's no better default point of division than age 99.
(Of course, it is to be anticipated that those defaults will be
modified immediately by users to fit their requirements.)

The natural-language description of this sequence is correct. Nothing
can be wrong except the enablement of the buttons. And the "Add" button
should be disabled because it cannot perform any correct action. (If the
user reduces the limiting age, then "Add" should of course be enabled.)

That problem is the root cause of all the ugly symptoms. Resolving it
would justify making the code reasonably more complex. I don't know
whether it's actually feasible. I'm sure we don't need to address this
before Halloween, but I'd test a patch now and apply it later. Or, if
it's not feasible, let's document the reason for deciding not to fix it.