Re: [lmi] axes editing controls

[Greg Chicares]

On 2007-11-29 12:30Z, Vadim Zeitlin wrote:
> On Thu, 29 Nov 2007 05:23:45 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> > What I'm aiming for is not 
> GC> > necessarily using single (C++) type for all axes here, but single 
> GC> > base type more specific than wxWindow, so that we can manipulate the 
> GC> > control without dynamic_cast<>:
> GC> 
> GC> AFAICT, if you want, you can actually go all the way to the
> GC> perfect simplicity of one single C++ type (wxComboBox) for all
> GC> axes.
> 
>  I'm a bit confused here: do you really mean wxComboBox and not wxChoice?

My mistake. Now I see that I have never understood wxChoice at
all. My incorrect analogy was
  wxChoice : 'control' :: wxSingleChoiceDialog : 'dialog'
so I thought it was some kind of listbox that always takes up
lots of room on the screen. And here we don't want to take up
a lot of room--what we want is the thing msw calls a COMBOBOX
with a CBS_DROPDOWNLIST style. I had thought that meant a
wxComboBox with style wxCB_DROPDOWN|wxCB_READONLY . But now I
read wx file 'src/msw/choice.cpp' and see that wxChoice *is* a
COMBOBOX with CBS_DROPDOWNLIST style.

So that I can learn from this mistake, please tell me whether
the following hypothesis is true:
  If I have a wxComboBox with style wxCB_DROPDOWN|wxCB_READONLY,
  and I restrict myself to the wxControlWithItems interface plus
  GetCurrentSelection(), then I can substitute a wxChoice for
  the wxComboBox and there should be no observable difference.
If that substitution principle holds, then I suspect I can
simplify some of the code I've written.

> wxComboBox allows entering values not present in the list of choices, do we
> really want this?

We do not want that. We'd rather forbid it.

> It may make sense to allow entering the age or duration
> directly but IMHO it would be a bad idea to do it for other fields.

I never thought of doing that before. But now I've looked at
it, and I think it's a bad idea even for age and duration
fields. Here's why. Those fields may contain consecutive
integers in, say, [0, 100]. Suppose I want to select '29'.
If I type '2' then '9', then here's what happens:
  type '2': '2' is selected; then
  type '9': '9' is selected
but ideally '29' would be selected, not '9'.

Now, perhaps your point is that we could get the "ideal"
behavior if we used what msw calls a COMBOBOX with style
CBS_DROPDOWN (not CBS_DROPDOWNLIST). I'm not sure whether
that would work, or whether it would create the harmful
possibility of entering a selection not on the list; but
it doesn't matter, because the "ideal" property that '29'
could be selected by typing '2' then '9' is an "ideal"
that is of negligible value.

The reason why it has no real value is that, as discussed
previously, these comboboxes filled with consecutive integers
aren't often used, and it's not worth making any effort or
complicating the code to make them work more "nicely". They
just aren't very nice to work with, and that's all right
because of the nature of the product-editor problem domain.

>  Could you please clarify whether you really want to use wxComboBox for all
> the axes?

This decision should be made by people who understand wx far
better than I do. Let me just point out this rationale for
preferring wxComboBox, in a random message I stumbled upon:

  http://lists.wxwidgets.org/archive/wx-users/msg51872.html

...which brings this wxGTK comment to mind:

On 2007-11-20 23:51Z, Vaclav Slavik wrote:
|
| Currently, both of these controls are always implemented as wxChoice,
| even for axes like Issue Age or Duration, where the list of allowed
| values is rather large integer range. Would wxSpinCtrl be better
| suited here? Picking Duration value from 100-items choice control
| that doesn't even fit on screen and needs scrolling under wxGTK can
| be a bit tiresome...

I've never built lmi with wxGTK, so perhaps I didn't pay enough
attention to that comment, guessing that the "scrolling" problem
would appear on any conceivable platform--but not suspecting that
it might be far worse on gtk than on msw. Today, 100% of our end
users run msw, but that could change someday; and if there's a
simple way to avoid a gtk problem without harming msw, then that
would seem like a good idea.

But you know much more about this than I do, so I should leave
the decision entirely up to you.