Re: [lmi] TAB and focus handling in MvcController (was: Input-sequence editor testing)

[Vadim Zeitlin]

On Sun, 10 Jul 2011 21:16:57 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2011-07-09 23:39Z, Vadim Zeitlin wrote:
GC> > On Sat, 09 Jul 2011 23:27:40 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC> For example, [on the "Payments"]
GC> > GC> notebook tab type '-1' in "Dumpin"; now focus is locked in that field,
GC> > GC> and neither Enter, Tab, nor clicking elsewhere will move the focus 
(but
GC> > GC> Cancel remains enabled).
GC> > 
GC> >  Did you also use wxTE_PROCESS_TAB to force this?
GC> 
GC> No.
GC> 
GC> > Because AFAIK it's the
GC> > only way to prevent TAB from working.
GC> 
GC> Trompe-l'œil. MvcController::UponChildFocus() doesn't prevent Tab (etc.)
GC> from working; instead, it detects when it has worked, and negates the
GC> effect by switching focus back faster than the eye can see.

 While you do need to do something about losing focus when the control has
invalid value because the focus can always be switched with the mouse, I
think it would be better to avoid losing it in the first place if possible
and disable using TAB for navigation if the validation fails. This should
be as simple as

(1) Adding wxTE_PROCESS_TAB to all text and spin controls.
(2) Only skipping the EVT_CHAR event generated for WXK_TAB if the
    validation passes.

If you wish, I can look into making a patch implementing this.


 Of course, this probably doesn't make much sense as long as you need to
keep the (complicated and brittle, IMO) code in UponChildFocus() anyhow.
Personally, I think that preventing the control from losing focus if its
contents is invalid is a wrong strategy of dealing with the user input.
In addition to the issues you already ran into it that are documented in
the comment preceding UponChildFocus(), there is also the fact that this
approach makes it impossible to edit the controls whose validity depends on
each other in the order preferred by user, i.e. you can't make a control A
value temporarily invalid and then update control B to make it finally
valid. In the extreme (and, admittedly, unlikely) case when both controls
depend on each other it may even prevent the user from entering some data
at all.

 Because of this I much prefer highlighting, in some way (a typical one is
to make the control background red; another one, popularized by web pages
UI, is to put a small warning icon near it; there are many others), the
controls with invalid data but leaving the user the liberty to navigate the
screen as he wishes. This simplifies both the code and the user experience
and I really don't see any good reason to lock down the latter and increase
the complexity of the former.

 I realize that you might have more important things to keep you busy with
but if, by chance, you'd be interested in pursuing this idea further,
please let me know.

 Regards,
VZ