[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.platform.swt] Re: Dialog eating selection events

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;
    }
});

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.

Grant


"David Huebel" <davidhuebel@xxxxxxxxxxx> wrote in message
news:fu01gj$nhn$1@xxxxxxxxxxxxxxxxxxxx
> I have a custom widget (a Composite subclass) that I use in my application
> window and in a org.eclipse.jface.dialogs.Dialog subclass.  Inside this
> widget I have various Texts.  When a user presses "Enter" in a text box, I
> run a search and update the widget.  Each Text has a SelectionListener
that
> triggers the search job.
>
> This works fine when the widget is inside the application window.
However,
> when the widget is in the dialog area of my Dialog subclass,
> pressing "Enter" always triggers the default button of the Dialog.  I
> thought about setting doit to false on the SelectionEvent, but my
> SelectionListeners are never run, so I don't have the opportunity.
>
> How do I consume default selection events in my widget to stop them from
> propagating up to the dialog?  (When focus is elsewhere in the dialog, but
> not in my widget, I want "Enter" to trigger the dialog's default button as
> usual.)
>
> Thanks,
> David
>