| control vs. listener event processing order [message #448322] |
Fri, 07 January 2005 11:39  |
Eclipse User |
|
|
|
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 #448412 is a reply to message #448406] |
Sat, 08 January 2005 11:39  |
| Eclipse User |
|
|
|
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 |
 Steve Northover
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
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.03904 seconds
] 
Search
Help
Register
Login
Home
