[news.eclipse.platform.swt] Re: Dialog eating selection events

[David Huebel <davidhuebel@xxxxxxxxxxx>]

Grant Gayed wrote:

> Hi David,
> 
> The better way to be notified of the user pressing Enter/Return in your
> Text is with a Traverse listener like:
> 
> text.addTraverseListener(new TraverseListener() {
>     public void keyTraversed(TraverseEvent e) {
>         boolean returnPressed = e.detail == SWT.TRAVERSE_RETURN;
>         // e.doit = !returnPressed;
>     }
> });

Thanks, Grant; this worked perfectly.  I check for the CNTRL modifier and
set e.doit to false for Enter and true for Cntl+<Enter>, so
keyboard-centric users can still navigate.

> 
> If you really want to veto the default button selection then you can
> uncomment the "e.doit..." line.  However if your main concern is just with
> receiving this notification so that you can do something with the Text's
> value, then not vetoing the default button selection is the better UI
> practice.

That's interesting; it didn't even occur to me until you mentioned it, but
it makes logical sense.  Pressing <Enter> should be the same as clicking
the "Ok" button.  However, I know from users' complaints that they strongly
expect <Enter> to trigger a search, not dismiss the dialog, and they are
having trouble detraining themselves from this behavior.  They are
constantly accidentally dismissing the dialog after setting up their search
parameters.

Perhaps they use the web so much that their expectations of desktop GUI
applications are more strongly colored by web applications than by other
GUI applications.

-David