Re: [lmi] Allow direct drill-down editing in census manager

[Wendy Boutin]

On 2010-07-25 18:25, Vadim Zeitlin wrote:
> On Sun, 25 Jul 2010 23:27:14 +0200 Vaclav Slavik <address@hidden> wrote:
>
> VS> On Sat, 2010-07-24 at 16:48 +0200, Vadim Zeitlin wrote:
> VS> > wxDataViewCtrl also looks better, especially under non-MSW platforms
> VS> > (it doesn't have native implementation for the main part of the
> VS> > control under MSW), but the main reason to choose it would be to be
> VS> > able to allow for hierarchical structure.

The only use I see for the hierarchical structure in the context of
a census manager would be in distinguishing among our case, class,
and cell levels. Though, that's been a solid implementation for the
near-decade that I've used our system. Today, I'm not sure we'd gain
much with that structure except the possibility of changing the way
we handle case, class and cell in the future, which might be a good
enough reason.

I've seen the hierarchical structure used in an old vendor system as
a way to pick which columns should appear in the census manager. It
was very confusing because it only contained a subset of all possible
columns and the order of the columns aligned with the controls as
they appeared in the user interface. That could get messy with more
than one "skin". Maybe it was just a poor implementation, but it still
left me with an impression of what not to do.

>  FWIW I definitely agree with using wxDataViewCtrl, I just was trying to
> describe the possibilities. As I see it now, wxDataViewCtrl is better than
> wxListCtrl because all the cells (and not just the first one) need to be
> editable and it's better than wxGrid because of the reasons you gave and,
> equally, importantly, I don't think we need any wxGrid-only features (such
> as overlapping/merged cells) here.

I did some comparison testing of wxDataView and wxGrid using
the wx samples. In general, I favor wxGrid over wxDataView if
all possibilities exist in the current samples' implementations.
In particular, the navigational nature of wxGrid allows me to
easily edit columns, which is a very important attribute to users
who would typically edit the same parameter for each cell. For
example, premiums might be reallocated among a whole group, so
users will want to edit just the premium column in every row.
The tree-control nature of wxDataView seems very limiting for
navigating among columns unless I'm just not seeing an easy way
to do that with the keyboard.

I think there may be a few nuances lingering in the dataview
sample, so I've pointed them out here in case they interest you:
- Three clicks seemed reliably necessary to edit a control until
   I slowed down my mouse-clicking, now it's only two. I suppose
   the first click activates the control and the second click is
   to begin the editing, but it seems very unnatural and feels
   like a defect if you're a fast clicker, like me.
- Similar (but different) behavior exists on the dialog that has
   the toggle checkboxes. Click very slowly on the same checkbox
   to toggle its state and observe how many clicks are required
   before it actually changes (I stopped counting at twenty). A
   double-click seems to change it, but that's different behavior
   from what I'd expect and from what's in the grid sample.
- I prefer using the keyboard for navigating between cells, but
   that functionality doesn't exist in the dataview sample today.
   However, I understand its available to the control and just
   not implemented in the sample.

Is it possible to sort a wxGrid by columns? I don't think that's
necessarily a requirement for our census manager, but its a nice
feature if its available. I just couldn't find a way to do it in
the sample.