Re: [lmi] Input-sequence editor testing

[Vadim Zeitlin]

On Sat, 09 Jul 2011 23:27:40 +0000 Greg Chicares <address@hidden> wrote:

GC> > Currently, if OK is disabled, then Enter works as before, i.e. goes
GC> > to the next control.
GC> 
GC> Yes, thanks, I hadn't noticed that. One way to see it is to set
GC> "Individual payment" to
GC>   0 53; 0 @99; 0
GC> then edit it with "..." and click the up-arrow on the top row's
GC> spincontrol (changing its value to 54). An appropriate diagnostic is
GC> displayed, and the "OK" button is disabled, exactly as expected. But
GC> Enter still moves the focus to the next field; I'd prefer that focus be
GC> retained in the spincontrol that contains "54", because that's what lmi
GC> does elsewhere.

 We'd need to use wxTE_PROCESS_ENTER flag for the spin control for this as
the default behaviour is indeed to pass the focus to the next control.

GC> For example, hit Cancel to escape the sequence editor, and on the same
GC> notebook tab type '-1' in "Dumpin"; now focus is locked in that field,
GC> and neither Enter, Tab, nor clicking elsewhere will move the focus (but
GC> Cancel remains enabled).

 Did you also use wxTE_PROCESS_TAB to force this? Because AFAIK it's the
only way to prevent TAB from working.

GC> > I don't know whether that's standard Windows behavior or not, though
GC> > -- Vadim, do you?
GC> 
GC> I always thought Enter's standard behavior was to press the default
GC> pushbutton.

 Yes, definitely, when it exists and is enabled. I'm almost sure that if
the default button doesn't exist, Enter should pass the focus to the next
control. The case when the default button does exist but is disabled is
less clear, I could try to find out if you're interested.

 But if you don't want this to happen whatever the default native behaviour
can be, using wxTE_PROCESS_ENTER and handling the resulting event (and just
not doing anything, including not calling wxEvent::Skip(), in the handler)
should be enough to implement it.

 Regards,
VZ