Re: [lmi] Input-sequence editor testing

[Greg Chicares]

On 2011-07-09 17:32Z, Václav Slavík wrote:
> 
> On 9 Jul 2011, at 18:29, Greg Chicares wrote:
>> 
>> (2) In the input-sequence editor, Enter navigates to the next control. 
>> Elsewhere
>> in lmi, Enter triggers the default pushbutton; can that same style be used 
>> here
>> for consistency? Inserting 'ok_button_->SetDefault()' near the bottom of
>> InputSequenceEditor::InputSequenceEditor() seems to work, but I'm not sure
>> whether something bad would happen if the button is disabled as mentioned 
>> here:
> 
> No, not at all, that's the right thing to do, sorry for not doing it myself in
> the first place.

Okay, I'll insert that line right after the buttons are realized:

     buttons->Realize();
+    ok_button_->SetDefault();

     top->Add(buttons, wxSizerFlags().Expand().Border());

>> (Of course, if the sequence is invalid, then "OK" should be disabled, and the
>> Enter key shouldn't really do anything.)
> 
> Currently, if OK is disabled, then Enter works as before, i.e. goes to the 
> next control.

Yes, thanks, I hadn't noticed that. One way to see it is to set "Individual 
payment" to
  0 53; 0 @99; 0
then edit it with "..." and click the up-arrow on the top row's spincontrol 
(changing its
value to 54). An appropriate diagnostic is displayed, and the "OK" button is 
disabled,
exactly as expected. But Enter still moves the focus to the next field; I'd 
prefer that
focus be retained in the spincontrol that contains "54", because that's what 
lmi does
elsewhere. For example, hit Cancel to escape the sequence editor, and on the 
same notebook
tab type '-1' in "Dumpin"; now focus is locked in that field, and neither 
Enter, Tab, nor
clicking elsewhere will move the focus (but Cancel remains enabled).

> I don't know whether that's standard Windows behavior or not, though -- 
> Vadim, do you?

I always thought Enter's standard behavior was to press the default pushbutton.

Let me explain why I care about this. Most of our end users are familiar with 
other
illustration systems. Most of those other systems have quirky, nonstandard 
GUIs. Some
were originally written for DOS:
  "Type a number here (press the Enter key when done):"
and when they moved to msw, they violated CUA by making Enter behave like Tab, 
because
that seemed closest to the DOS behavior. Decades later, they're still doing 
that, and
they've misled some users to believe that's what Enter really should do in a 
GUI. I've
been asked to do the same, more than once; in reply, I ask them to show me 
where Enter
works that way in the dialogs of commercial software (word processors, 
browsers, etc.).
Of course they can't (because the behavior violates CUA), so we can agree not 
to work
on the "enhancement" request. However, it'll be harder to sustain that 
agreement if
part of lmi starts behaving that way--so let's just not go there please.

We don't need to address that immediately. I've been studying your patches for 
a long
time, while keeping them in my local tree, and it'll be easier for me to get 
them all
committed before changing anything (except perhaps for simple changes like
+    ok_button_->SetDefault();
above). We hope to offer the input-sequence editor to end users at the end of 
August
and no earlier, so there's still plenty of time to make changes and test them.