Re: [lmi] Drill-down census editor observations

[Václav Slavík]

Hi,

On 31 Oct 2013, at 16:56, "Murphy, Kimberly" <address@hidden> wrote:
> A. While testing various controls (i.e., textbox, radiobutton, spin 
>   control, etc.), I observed that the Product Name is text and not 
>   a drop-down list (as on the Plan tab in the GUI). This may be 
>   problematic to some users having to remember a products exact 
>   spelling and naming convention.

This is strange. If the Product Name is declared as an mc_enum in the model 
(which it seems to be to me), then it should be picked as such by CensusView. 
I'll investigate.

> B. In the current production census view, data in columns with a 
>   fixed width are left aligned ('...' at the right); now, they 
>   are center aligned ('...' in the center). Initially, I was not 
>   enthusiastic about the switch, but after testing with it for 
>   a while, one gets used to it. My personal preference is to 
>   have as much of the cell's data in view from the beginning, 
>   as opposed to a little of the beginning and the end. Is this 
>   something that can be easily changed?   

Yes; I'll post a patch in a separate mail after I test it, but it should be 
straightforward.

> C. A double click of the mouse on the sizer of any column results 
>   in the same behavior as if I had selected 'Census | Varying column 
>   width'. The column width is defined by the longest field entry of 
>   all cells. This is good. I'd expect that if I were to edit any 
>   field, the full value would be visible to modify. While I found 
>   this to be true for numeric fields, it was not always the case 
>   with text, as the first character was cut off. 

I'll have a look at wxDataViewTextRenderer's width calculation -- I'd say it 
should account for the edit control's size, at least when the column is 
editable.

> D. Different results were observed directly editing a cell versus 
>   'Census | Edit cell'. 
...
> E. In the last example, the credited rate had caught my eye. In the 
>   following example, switching between a non-current rate and the 
>   current rate, did not yield the expected result. 
...

I admit I didn't entirely follow the descriptions, but could both of these be 
caused by lack of model harmonization after editing?

I implemented fields validation in these patches:

        http://lists.gnu.org/archive/html/lmi/2012-02/msg00008.html
        http://lists.gnu.org/archive/html/lmi/2012-02/msg00009.html

The bottom part of this email is also related:

        http://lists.gnu.org/archive/html/lmi/2012-01/msg00014.html

Unfortunately it seems that none of them were applied to the trunk. I _think_ 
that they should fix this issue, but I am not sure if the Harmonize() call from 
the latter is sufficient (more details in the linked mail). 

> F. User-friendly date fields are a plus. In production, dates are in 
>   Julian. For example, an Effective Date of 'August 23, 2011' would 
>   appear in census view as '2456528'. Now, the census view reflects 
>   '08/23/11'. The cool thing is when the user invokes inline editing, 
>   the date changes to the format defined by the user's device short 
>   date format (found in the Region and Language settings). Thus, when 
>   a user goes into edit mode, they'll see a familiar date format, 
>   '08/23/2011', '2011-Aug-23' or as in my case, '2011-08-23'. While 
>   this is a good thing, it would be best to have consistency and use 
>   the same "short date" format all the time, whether editing the cell 
>   or not.

What are your exact Region and Language settings? There's code to handle this 
already, but it apparently doesn't work as it should. Vadim, can you see 
anything wrong with this self-explanatory snippet:

    // Use wx for date formatting so that it is identical to the way 
wxDatePickerCtrl does it.
    wxDateTime const date = ConvertDateToWx(value_cast<calendar_date>(m_value));
    RenderText(date.FormatDate(), 0, rect, dc, state);

?

> G. On a navigation note, I encountered no difficulties with either 
>   the F2 or Enter keys to start inline editing. OTOH, a double-click 
>   of the mouse did not work as I would expect. Nothing happens when 
>   I click twice quickly-- but two individual clicks (i.e., click on 
>   field desired for particular cell, then click a second time) 
>   enabled the inline editing. IMO, users will be less than pleased 
>   with this behavior.

This -- the "slow double-click" -- is standard Windows behavior (see e.g. 
renaming files in Explorer). It would be highly unexpected if double-click 
triggered editing, because it is used to activate items everywhere else in 
Windows.

> A double-click should do something. 

This is hard to argue with, though. There is another patch that didn't make it 
into the current source tree that addresses this:

        http://lists.gnu.org/archive/html/lmi/2011-12/msg00016.html

It implements opening the editor on double-click, consistently with Windows UI 
expectations. There are some other changes to the behavior discussed in the 
thread (you'll have to search for "Allow opening cell editor with 
double-click", though, the archive doesn't link this first mail with the rest 
for some reason).

>   Left and right arrow keys rightly moved focus across cell lines. I 
>   personally kept hitting the Tab key to move the focus but it did 
>   nothing. I could utilize the Tab key was while in edit mode, to 
>   move the focus off the edited field to the next column. However, 
>   this behavior was inconsistent; sometimes the focus remained on 
>   the current edited cell and at others, absolutely nothing happened. 
>   It all depended which type of field I was on.

Tab is not used in wxDVC because it has a different use: switching controls, 
not navigating in the content. The reason why it behaves inconsistently can 
probably be attributed to the differences in editor controls. In particular, 
composite editors (such as input sequence ones) will be troublesome -- pressing 
Tab on the text field should arguably move focus to the [...] button and not 
dismiss the editor, shouldn't it?

Customizing LMI's control to use Tab for navigation should be possible; it's 
the interactions with open editors and the "normal" Tab behavior that I'm 
worried about. Still, it's certainly worth trying.

> H. Using the right arrow key, the focus moves to the first column. 
>   However, if the census has only one column, no focus is observed. 
>   I do observe the focus with a census having at least two columns. 
>   I'm puzzled why this would matter.

I think the single-column case is treated specially because there's nowhere to 
move the focus to -- if there's only one (editable) column, you can't move 
focus horizontally. And because the focus indicator is non-native, it's better 
to not render it unless it is actually needed, to avoid distracting the user. 
The focus is still on the selected row and F2 edits the (only) editable cell on 
the selected row; it is a special case when wxDVC behaves identically to native 
list views.

> I. Grayed out or unavailable fields in the GUI can be directly edited 
>   in the census view. I expected that they would be grayed out in 
>   some way to prevent editing. On an inforce extract for instance, 
>   grayed fields on the Inforce tab returned to the original value 
>   when I tried to edit them, while others changed behind the gray. 
>   This could be confusing to some users. If a field is non-editable 
>   in the GUI, I'd expect it to be non-editable in the census editor.

This was addressed by one of the unapplied patches I linked to above:

        http://lists.gnu.org/archive/html/lmi/2012-01/msg00014.html

> J. An oddity was noticed while experimenting with the column width 
>   during editing. The edit box did not expand/reduce along with the 
>   changing column size. 
...
>   I expected the edit box would expand with the double-click; as 
>   if I had double-clicked the sizer first, then directly edited 
>   the address.

Personally I would expect the editor to just close when you click outside of 
its area, I wonder what the native listview control does... In any case, this 
is clearly a bug in wxDVC and needs to be fixed one way or another.

Thanks,
Vaclav