[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] solve-related durations
From: |
Greg Chicares |
Subject: |
Re: [lmi] solve-related durations |
Date: |
Sun, 24 Aug 2008 16:37:10 +0000 |
User-agent: |
Thunderbird 2.0.0.16 (Windows/20080708) |
On 2008-08-23 14:27Z, Wendy Boutin wrote:
> I think there's an issue with the new solve-related
> age and time inputs.
>
> Alt F N I
> SolveEePrem
> 'ToAge' type in a different age and the default
> age is automatically re-displayed instead of the
> entered age. I can re-enter the age and it will
> stick after another try, or two.
>
> This is just one example--I observe the same behavior
> in the other age and year input fields that are similarly
> connected, i.e., *not* 'IssueAge'.
Those other "similarly connected" fields--are they all solve
inputs that were previously either okay or unavailable?
I think this is a generic problem that we've noticed before. I
find something similar in personal mail [0], though not in the
mailing-list archives. As in the wxDatePickerCtrl example in the
footnote, the exact behavior depends on the keystrokes that are
typed, and the control's contents just before each keystroke.
I tend to overlook the problem because I use the up- and down-
arrow keys to change values in a wxSpinCtrl.
I see three options:
(A) The One True Way: figure out exactly what's happening, and
why; then fix it in the right way, in the right place. That's not
likely to be possible before the 2008-09-01 release. I think we
have more than one issue with spincontrols, actually.
(B) Ignore it for now, then do (A) later. It's arguably not worse
than it used to be: half these spincontrols were always grayed,
and that was really bad. OTOH, it's now defective in a novel way.
Even though the issue is generic, perhaps we've suppressed it
everywhere else by not setting context-dependent limits on other
spincontrols; I don't believe we know that for sure.
(C) Suppress it for now, then do (A) later. I would guess that
the patch below [1] would make this spincontrol work like the one
for issue age. Or, instead, just change it to a textcontrol; then
I'd guess it'd work perfectly, except for losing the desirable
features that a spincontrol brings.
---------
[0] "something similar in personal mail"
This is a different problem with a different control, but shows
the sort of complexity we have to deal with for your testcase.
On 2006-06-15 17:00Z, Greg Chicares wrote:
[...]
| Consider a date picker with
| a range limited to [1906, 2006], and suppose you want to type
| the four digits 1 9 5 6 in the year field.
|
| Type '1' ... value becomes 2001.
| Then type '9' ... value 2019 would be out of range,
| so it stays 2001--and that seems weird.
| Then type '5' ... no, 195 is not a valid two-digit year,
| so it stays 2001.
| Finally, type '6' ... okay, now it's 1956.
|
| Here's the really bizarre thing:
| "19" is too high, but
| "1956" is not too high;
| yet 19 is manifestly less than 1956. I don't think any other
| control behaves like that.
|
| I suppose ms has built that into the control because they've
| decided that I should accept one- and two-digit years. I see
| no way to turn that off, so I was hoping to delay evaluating
| input until focus loss.
[1] "the patch below":
Index: input_harmonization.cpp
===================================================================
RCS file: /sources/lmi/lmi/input_harmonization.cpp,v
retrieving revision 1.73
diff -U 3 -r1.73 input_harmonization.cpp
--- input_harmonization.cpp 13 Aug 2008 01:31:18 -0000 1.73
+++ input_harmonization.cpp 24 Aug 2008 15:41:25 -0000
@@ -968,9 +968,11 @@
// INPUT !! The minimum 'SolveEndYear' and 'SolveTargetYear' set
// here mean that a solve to or at retirement is a request, not a
// command.
+#if 0 // http://lists.nongnu.org/archive/html/lmi/2008-08/msg00036.html
SolveBeginYear .minimum_and_maximum(0 ,
years_to_maturity());
SolveEndYear .minimum_and_maximum(SolveBeginYear.value(),
years_to_maturity());
SolveTargetYear.minimum_and_maximum(SolveBeginYear.value(),
years_to_maturity());
+#endif // 0
// INPUT !! Temporarily, existing -'Time' names are used where
// -'Age' names would be clearer.
@@ -978,9 +980,11 @@
SolveEndTime .enable(actually_solving && mce_solve_to_age ==
DeprecatedSolveToWhich);
SolveTargetTime.enable(actually_solving && mce_target_at_age ==
DeprecatedSolveTgtAtWhich && mce_solve_for_target == SolveTarget);
+#if 0 // http://lists.nongnu.org/archive/html/lmi/2008-08/msg00036.html
SolveBeginTime .minimum_and_maximum(issue_age() ,
maturity_age());
SolveEndTime .minimum_and_maximum(SolveBeginTime.value(),
maturity_age());
SolveTargetTime.minimum_and_maximum(SolveBeginTime.value(),
maturity_age());
+#endif // 0
SolveTarget.enable(actually_solving);
SolveTarget.allow(mce_solve_for_endt , actually_solving);