Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Standard Widget Toolkit (SWT) » control vs. listener event processing order
control vs. listener event processing order [message #448322] Fri, 07 January 2005 11:39 Go to next message
Eclipse UserFriend
Originally posted by: mmaercker.tripper-bullet.com

Hi all,

I need to react to a key event in a text control _after_ the control has
processed the event. Specifically, I want to know the line count of the text
control after the control had the chance to process the key so I can refresh
the composite layout if necessary (the control is always supposed to be
exactly large enough to show all lines of text it contains).

In the GUI wrappers I am familiar with (wxWindows and MFC), you can choose
between handling an event:
a) before the underlying control and then passing it to the control
b) before the underlying control and _not_ passing it to the control
c) after the underlying control has handled it

In SWT, the way I understand it now is that a) is the default behaviour and
b) can be achieved by things like setting boolean KeyEvent::doit. Is
there an official and guaranteed-to-work way to do c)?

I looked in the docs for org.eclipse.swt.events and in this news group but I
couldn't find any general information on the order of event processing. I
skimmed over the Text widget's sendKeyEvent source for the win32 SWT
implementation and, at first glance, it didn't look like any post processing
is supported. But I can't imagine I am the only one wanting to get a grab at
events after the control has handled them so I assume that I am overlooking
something. Any pointers would be greatly appreciated.

As an aside: if I do get around to refreshing the layout from a key event,
would I then have to make that call via Display::asyncExec(.)?


Thanks in advance,

Martin Maercker
Re: control vs. listener event processing order [message #448406 is a reply to message #448322] Fri, 07 January 2005 22:47 Go to previous messageGo to next message
Steve Northover is currently offline Steve NorthoverFriend
Messages: 1636
Registered: July 2009
Senior Member
Use Display.asyncExec() to run code after the key has been typed.

"Martin Maercker" <mmaercker@tripper-bullet.com> wrote in message
news:crls7r$b5h$1@www.eclipse.org...
> Hi all,
>
> I need to react to a key event in a text control _after_ the control has
> processed the event. Specifically, I want to know the line count of the
text
> control after the control had the chance to process the key so I can
refresh
> the composite layout if necessary (the control is always supposed to be
> exactly large enough to show all lines of text it contains).
>
> In the GUI wrappers I am familiar with (wxWindows and MFC), you can choose
> between handling an event:
> a) before the underlying control and then passing it to the control
> b) before the underlying control and _not_ passing it to the control
> c) after the underlying control has handled it
>
> In SWT, the way I understand it now is that a) is the default behaviour
and
> b) can be achieved by things like setting boolean KeyEvent::doit. Is
> there an official and guaranteed-to-work way to do c)?
>
> I looked in the docs for org.eclipse.swt.events and in this news group but
I
> couldn't find any general information on the order of event processing. I
> skimmed over the Text widget's sendKeyEvent source for the win32 SWT
> implementation and, at first glance, it didn't look like any post
processing
> is supported. But I can't imagine I am the only one wanting to get a grab
at
> events after the control has handled them so I assume that I am
overlooking
> something. Any pointers would be greatly appreciated.
>
> As an aside: if I do get around to refreshing the layout from a key event,
> would I then have to make that call via Display::asyncExec(.)?
>
>
> Thanks in advance,
>
> Martin Maercker
>
>
>
>
>
>
>
>
Re: control vs. listener event processing order [message #448412 is a reply to message #448406] Sat, 08 January 2005 11:39 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: mmaercker.tripper-bullet.com

> Use Display.asyncExec() to run code after the key has been typed.

Thanks,

just to make sure I understand:

If a listener to a control reacts to an event and I don't use asyncExec(),
the code in the listener is executed before the control handles the event.

If I use asyncExec() in the listener the listener's execution is blocked
until after the control handled the event.

In both cases thread safety is maintained as long as the listener only
invokes methods on objects that are accessed only in the UI thread.

Is that correct?


Best regards,

Martin


"Steve Northover" <steve_northover@ca.ibm.com> schrieb im Newsbeitrag
news:crn3ig$qid$1@www.eclipse.org...
> Use Display.asyncExec() to run code after the key has been typed.
>
> "Martin Maercker" <mmaercker@tripper-bullet.com> wrote in message
> news:crls7r$b5h$1@www.eclipse.org...
> > Hi all,
> >
> > I need to react to a key event in a text control _after_ the control has
> > processed the event. Specifically, I want to know the line count of the
> text
> > control after the control had the chance to process the key so I can
> refresh
> > the composite layout if necessary (the control is always supposed to be
> > exactly large enough to show all lines of text it contains).
> >
> > In the GUI wrappers I am familiar with (wxWindows and MFC), you can
choose
> > between handling an event:
> > a) before the underlying control and then passing it to the control
> > b) before the underlying control and _not_ passing it to the control
> > c) after the underlying control has handled it
> >
> > In SWT, the way I understand it now is that a) is the default behaviour
> and
> > b) can be achieved by things like setting boolean KeyEvent::doit. Is
> > there an official and guaranteed-to-work way to do c)?
> >
> > I looked in the docs for org.eclipse.swt.events and in this news group
but
> I
> > couldn't find any general information on the order of event processing.
I
> > skimmed over the Text widget's sendKeyEvent source for the win32 SWT
> > implementation and, at first glance, it didn't look like any post
> processing
> > is supported. But I can't imagine I am the only one wanting to get a
grab
> at
> > events after the control has handled them so I assume that I am
> overlooking
> > something. Any pointers would be greatly appreciated.
> >
> > As an aside: if I do get around to refreshing the layout from a key
event,
> > would I then have to make that call via Display::asyncExec(.)?
> >
> >
> > Thanks in advance,
> >
> > Martin Maercker
> >
> >
> >
> >
> >
> >
> >
> >
>
>
Re: control vs. listener event processing order [message #448459 is a reply to message #448412] Mon, 10 January 2005 17:48 Go to previous message
Steve Northover is currently offline Steve NorthoverFriend
Messages: 1636
Registered: July 2009
Senior Member
In the case of the key listener, the operating system code that inserts a
character into the control runs after your listener. That way, you get to
cancel it. Also, thread safety is always maintained. All public widget API
is check to make sure you are running in the UI thread. You'll need to make
sure the control is not destroyed in the asyncExec() runnable. Other than
that, you should be ok.

"Martin Maercker" <mmaercker@tripper-bullet.com> wrote in message
news:crogke$pni$1@www.eclipse.org...
> > Use Display.asyncExec() to run code after the key has been typed.
>
> Thanks,
>
> just to make sure I understand:
>
> If a listener to a control reacts to an event and I don't use asyncExec(),
> the code in the listener is executed before the control handles the event.
>
> If I use asyncExec() in the listener the listener's execution is blocked
> until after the control handled the event.
>
> In both cases thread safety is maintained as long as the listener only
> invokes methods on objects that are accessed only in the UI thread.
>
> Is that correct?
>
>
> Best regards,
>
> Martin
>
>
> "Steve Northover" <steve_northover@ca.ibm.com> schrieb im Newsbeitrag
> news:crn3ig$qid$1@www.eclipse.org...
> > Use Display.asyncExec() to run code after the key has been typed.
> >
> > "Martin Maercker" <mmaercker@tripper-bullet.com> wrote in message
> > news:crls7r$b5h$1@www.eclipse.org...
> > > Hi all,
> > >
> > > I need to react to a key event in a text control _after_ the control
has
> > > processed the event. Specifically, I want to know the line count of
the
> > text
> > > control after the control had the chance to process the key so I can
> > refresh
> > > the composite layout if necessary (the control is always supposed to
be
> > > exactly large enough to show all lines of text it contains).
> > >
> > > In the GUI wrappers I am familiar with (wxWindows and MFC), you can
> choose
> > > between handling an event:
> > > a) before the underlying control and then passing it to the control
> > > b) before the underlying control and _not_ passing it to the control
> > > c) after the underlying control has handled it
> > >
> > > In SWT, the way I understand it now is that a) is the default
behaviour
> > and
> > > b) can be achieved by things like setting boolean KeyEvent::doit. Is
> > > there an official and guaranteed-to-work way to do c)?
> > >
> > > I looked in the docs for org.eclipse.swt.events and in this news group
> but
> > I
> > > couldn't find any general information on the order of event
processing.
> I
> > > skimmed over the Text widget's sendKeyEvent source for the win32 SWT
> > > implementation and, at first glance, it didn't look like any post
> > processing
> > > is supported. But I can't imagine I am the only one wanting to get a
> grab
> > at
> > > events after the control has handled them so I assume that I am
> > overlooking
> > > something. Any pointers would be greatly appreciated.
> > >
> > > As an aside: if I do get around to refreshing the layout from a key
> event,
> > > would I then have to make that call via Display::asyncExec(.)?
> > >
> > >
> > > Thanks in advance,
> > >
> > > Martin Maercker
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
>
>
Previous Topic:Calculating table column width
Next Topic:Combo processing
Goto Forum:
  


Current Time: Thu Oct 22 17:43:58 GMT 2020

Powered by FUDForum. Page generated in 0.02058 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top