Re: [lmi] InputSequence questions

[Vaclav Slavik]

On Thu, 2010-04-01 at 21:50 +0000, Greg Chicares wrote: 
> I suppose that requiring the MinGW threading dll is just an incidental
> artifact of the way you built the demo, and that you're not actually
> using more than one thread.

Yes.

> > and the look isn't polished yet on Windows, either. (In particular,
> > wxMSW stock icons are unusable and I was hoping for borderless "-Remove"
> > buttons that would get button look when the mouse hovers atop them, but
> > wxMSW doesn't want to cooperate... yet.)
> 
> I'm not sure we need special buttons that would be unlike anything
> else presently in lmi.

My reasoning was that the buttons shouldn't attract too much attention
to themselves and thus distract from the main data-entering part of the
UI. Regular buttons are heavyweight objects so that they _do_ attract
attention; put a battery of them along the right side and "heavy"
doesn't even begin to describe the effect.

Using a bitmap-only button helps a bit and so would, hopefully,
indenting the buttons even more from the main area.

> If I pick "for # years" from the combobox, I observe a repaint
> issue. The combobox's drop-down arrow is painted into the left
> end of the textcontrol to its right, obscuring the number entered
> there. It looks like that number has vanished, though it hasn't
> really.

This can probably be dealt with a by an extra Refresh() call; more
interesting would be understanding why it happens.

> If I change the to-maturity default, another row is automatically
> added, as intended. But the second row's combobox is about fifty
> pixels high. 

I suspect there's some bug in size-determination code that shows up when
called at the time the choice's popup window is still visible -- this
bug doesn't happen if using keyboard to change choice's value.

> I think we need to see this with numerous rows and many different
> combobox selections in order to judge how well the language reads.
> I see "from after 33 years until", for example, which seems rough;
> maybe we could find other wording, but that would be much easier
> with some more polish in the demo.

I hoped this demo would be sufficient for exactly this :-/ 
IMHO, this wording is unusable and the editable one ("until [for #
years]") isn't much better.

Here's an idea for the "from" column: instead of the current text, find
the preceding endpoint expressed in _absolute_ terms, and express "from"
relative to it:

   from issue date           until [retirement]
   from retirement           until [for # years] [  5]
   from retirement + 5 yrs   until [for # years] [ 10]
   from retirement + 15 yrs  until [maturity]

What do you think?

For the editable one, putting "from" into the choice control ("until
retirement", but "for # years") would be better, but it would harm
keyboard use.

> I imagine there's a default context for the input sequence, e.g.,
> issue age zero and so on. 

I don't know, is there? That is, do we know these parameters everywhere
input sequences are edited?

> It'd be helpful to have a default other
> than zero. That way, we could ascertain whether
>   from issue date until [#years] [7]
> gets changed to, e.g.,
>   from issue date until [  age ] [default issue age + 7]
> when we change the combobox selection.

This is great idea (assuming we have the data at the time of editing).

> The default context--issue
> age, retirement age, maturity duration IIRC--doesn't need to be
> displayed; it's okay if you just write it in an email.

I didn't use any, I assumed that the whole point of expressing and
editing the sequences in an abstract way that you don't know these at
the time of editing...

> The popup dialog widens and shrinks when the combobox selection
> changes. I think it'd be less surprising if we could use constant
> spacing. 

Yes, of course.

> The grammar for the "from X until" phrase is simple, so
> I think we can determine a width that would always suffice. It'd
> be helpful to see that in the demo so that we can judge whether
> that width appears excessive when the phrase is short (but I
> suspect that won't be a problem).

_And_ if it was, it would be a problem even with shrinkable width.

Vaclav