Re: [lmi] switch census view to use wxDataViewCtrl

[Greg Chicares]

On 2011-08-03 14:41Z, Václav Slavík wrote:
> 
> On 3 Aug 2011, at 16:22, Greg Chicares wrote:
>> My answer to both questions is that we needn't go against the standard
>> convention--as long as some row always has "command focus", so that commands
>> always operate on some row...if that is possible with wxDataViewCtrl, which
>> I suspect it might not be.
> 
> It almost certainly is possible (you can set selection to something as soon
> as you detect that the selection became empty), but as Vadim noted, it may be
> better not to. It's not native behavior and it's IMHO quite surprising when
> such thing happens.

Okay, you have persuaded me to change my opinion thus:
  if the control enters the zero-rows-selected state through deliberate user
    action, then commands that require a selection become unavailable
and that's sufficient to honor the native behavior. But I still balk at
letting the control enter that state without deliberate user action, so I
propose that we select some row programmatically both when the control is
created, and when selected rows are deleted. Does that feel okay to you?
(As you point out below, it's possible that we've overlooked some other
way it can enter that state, but I'm okay with that--if we discover such
a way, then we can address it after we become aware of it).

> I think it should be left to behave natively, i.e. make it possible to
> deselect everything.

Okay.

> Note that it's not really an issue in practice: as soon as you hit an
> arrow key (without modifiers), focus moves to a new item and selection
> is set to equal the focus.

Yes, except in the important case where the census has exactly one row.
For example:
  File | New | Census
None of the arrow keys cause the row to be selected. With the old listview
implementation and wx-2.9.0, any of the four arrow keys selected it. Is
that a deliberate difference between wxLV and wxDVC, or do you see it as a
wxDVC anomaly that should be changed in a future wx release?

(I know now that Home, End, PgUp, and PgDn act the way I expect the arrow
keys to in the above example, but my habit is to use the arrow keys, and
I was surprised that they didn't work.)

If you want to make wxDVC's behavior more similar to wxLV's, then let me
suggest removing the focus rectangle that surrounds the first item upon
creation--for wxDVC but not for wxLV.

>>  File | New | Census
>>  Census | Delete cell(s)
>> produces this messagebox:
>>  Confirm deletion
>>  Irrevocably delete 0 of 1 cells?
>>  Yes   No
>> which looks like a logic error. ("Obviously that's a no-op, so why ask me to
>> confirm whether or not I want to do...nothing?") In that testcase, the first
>> (and only) cell has the "focus rectangle" but no "selection highlight", and
>> menu commands do not apply to it: that's the regression I want to fix, and
>> I'm guessing that to do so we need (at least) one row to have "selection"
>> as well as "focus".
> 
> Yes. But I think the right thing would be disable all these commands if 
> there's
> no selection, thus making the above situation impossible -- just as some 
> commands
> are disabled in case of multiple selection now. I consider it preferable to 
> doing
> unexpected things with the selection.

Okay.

> I'd also modify the Delete cell(s) operation to set selection to something
> reasonable after it's done -- that's the only (or in any case, the most 
> common)
> case when you can end up with empty selection without doing it intentionally.

Agreed.

> And it does make sense to select the first row that will now occupy the place
> of deleted rows.

If you have rows representing all uppercase ASCII letters, and you delete B and 
F,
then the selection could be set to A or C, or E or G; I don't think it matters
which of those we choose. (Of course, if A and Z are deleted, we'd have to pick
either B or Y.)

>> It was possible (but, importantly, more difficult) to get that "delete 
>> nothing?
>> messagebox with a wx-2.9.0 version of lmi, by doing Ctrl-left_click on the 
>> last
>> selected row...so this is an old lmi anomaly that's just more likely to arise
>> with the wxDataViewCtrl implementation.
> 
> That's why I think we should disable the commands instead. Playing tricks with
> the selection risks to leave some way to trigger this open.

Yes, that's a good point, too.

>> Also, again with an older version, if I
>> make a census with two cells, select the second, and then unselect so that it
>> keeps the focus rectangle...and then do "Census | Edit cell", it's the 
>> (unfocused)
>> first cell that's edited, not the second; shouldn't the focused cell have 
>> been
>> used in the listview implementation, or do I still misunderstand how this 
>> works?
> 
> The focus is really only for keyboard navigation and it's only use (in 
> listview or
> currently; it will be useful for navigation within wxDVC columns later) is to
> select multiple non-neighbouring items via Ctrl-arrows and Space. It doesn't 
> take
> the role of selection even in absence of "real" selection.

Okay, thanks for explaining that--I didn't find a good explanation in msdn.