lmi
[Top][All Lists]
Advanced

[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);




reply via email to

[Prev in Thread] Current Thread [Next in Thread]