Re: [lmi] Drill-down census editor observations

[Vadim Zeitlin]

On Fri, 1 Nov 2013 15:00:22 +0100 Václav Slavík <address@hidden> wrote:

VS> > F. User-friendly date fields are a plus. In production, dates are in 
VS> >   Julian. For example, an Effective Date of 'August 23, 2011' would 
VS> >   appear in census view as '2456528'. Now, the census view reflects 
VS> >   '08/23/11'. The cool thing is when the user invokes inline editing, 
VS> >   the date changes to the format defined by the user's device short 
VS> >   date format (found in the Region and Language settings). Thus, when 
VS> >   a user goes into edit mode, they'll see a familiar date format, 
VS> >   '08/23/2011', '2011-Aug-23' or as in my case, '2011-08-23'. While 
VS> >   this is a good thing, it would be best to have consistency and use 
VS> >   the same "short date" format all the time, whether editing the cell 
VS> >   or not.
VS> 
VS> What are your exact Region and Language settings? There's code to
VS> handle this already, but it apparently doesn't work as it should.
VS> Vadim, can you see anything wrong with this self-explanatory snippet:
VS> 
VS>     // Use wx for date formatting so that it is identical to the way 
wxDatePickerCtrl does it.
VS>     wxDateTime const date = 
ConvertDateToWx(value_cast<calendar_date>(m_value));
VS>     RenderText(date.FormatDate(), 0, rect, dc, state);
VS> 
VS> ?

 I think the problem is not in this line on its own but is due to the fact
that LMI uses "C" locale instead of using the default GUI one. At least
this is my impression from looking at the code, I don't see any call to

    wxSetlocale(LC_ALL, "");

or setlocale() anywhere. And if neither function is called, FormatDate()
uses '08/23/11' format as this is the correct format for the default ("C")
locale.

 The trouble is that I don't really know if it's safe to change the locale
globally in LMI... So either it would need to be done and undone here or we
could try to format it in a different way but in absence of any specific
support for this in wxDateTime, it would have to be done extremely ugly,
e.g. by creating a hidden calendar control just as a formatter.

VS> > G. On a navigation note, I encountered no difficulties with either 
VS> >   the F2 or Enter keys to start inline editing. OTOH, a double-click 
VS> >   of the mouse did not work as I would expect. Nothing happens when 
VS> >   I click twice quickly-- but two individual clicks (i.e., click on 
VS> >   field desired for particular cell, then click a second time) 
VS> >   enabled the inline editing. IMO, users will be less than pleased 
VS> >   with this behavior.
VS> 
VS> This -- the "slow double-click" -- is standard Windows behavior (see
VS> e.g. renaming files in Explorer). It would be highly unexpected if
VS> double-click triggered editing, because it is used to activate items
VS> everywhere else in Windows.

 Let me just chime in with support for this behaviour: this is exactly how
it works in Explorer and I think people shouldn't be too displeased by
finding the same behaviour here.

VS> >   Left and right arrow keys rightly moved focus across cell lines. I 
VS> >   personally kept hitting the Tab key to move the focus but it did 
VS> >   nothing.
...
VS> Tab is not used in wxDVC because it has a different use: switching
VS> controls, not navigating in the content. The reason why it behaves
VS> inconsistently can probably be attributed to the differences in editor
VS> controls. In particular, composite editors (such as input sequence
VS> ones) will be troublesome -- pressing Tab on the text field should
VS> arguably move focus to the [...] button and not dismiss the editor,
VS> shouldn't it?

 Yes, and I think that using wxEVT_CHAR_HOOK should help with implementing
this. But I could be missing something, of course...

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

 Yes, the situation here is very spreadsheet-like, so using TAB feels
natural. I'd also expect Enter to work in a spreadsheet-like way (maybe it
already does? I didn't test the latest version...).

VS> > J. An oddity was noticed while experimenting with the column width 
VS> >   during editing. The edit box did not expand/reduce along with the 
VS> >   changing column size. 
VS> ...
VS> >   I expected the edit box would expand with the double-click; as 
VS> >   if I had double-clicked the sizer first, then directly edited 
VS> >   the address.
VS> 
VS> Personally I would expect the editor to just close when you click
VS> outside of its area, I wonder what the native listview control does...

 It cancels editing when you click outside, even if it's just to resize the
column. On a slightly related note, it also always creates the editor big
enough to show the entire cell contents, even if it means making it wider
than the current column width -- which makes sense, IMHO.

 Thanks for looking at this!
VZ