Home » Eclipse Projects » Eclipse Platform » Propagating resource changes to an editor
| Propagating resource changes to an editor [message #114532] |
Fri, 22 August 2003 09:03  |
Eclipse User |
|
|
|
Building my first plug-in editor, I am trying to react to resources
changes. The first level is to refresh the viewers of the editor if the
file being edited has changed. I did implement a ResourceChangeListener
and a ResourceDeltaVisitor. However, when time comes to refresh the
viewers, I get an invalid thread exception because I am not in the thread
that created the viewer (since being called rfom the workspace, I
guess...).
Question: how do one refresh the viewers in such case?
Cheers,
Didier
|
|
|
| Re: Propagating resource changes to an editor [message #114642 is a reply to message #114532] |
Fri, 22 August 2003 10:17  |
| Eclipse User |
|
|
|
When do I call Display.asyncExec?
Rule of thumb: You never need to calll Display.asyncExec(), unless SWT
throws an "invalid thread access" exception at you.
On most operating systems, drawing to the screen is an operation that needs
to be synchronized with other draw requests to prevent chaos. A simple OS
solution for this resource contention problem is by allowing drawing
operations to occur only in a very special thread. Rather than drawing at
will, an application sends in a request to the OS for a redraw, and the OS
will call back the application at a time it deems appropriate. An SWT
application behaves in the same way.
When the end-user of your plugin activates a menu or pushes a button, the OS
will notify SWT, which in turn will call other plugins, that call other
plugins, until eventually the call-chain ends with you. All these calls are
made in the same event loop thread. Almost all code in Eclipse behaves this
way. Normally, no plugin acts on its own, but only reacts to stimuli from
others. In general, plugins are passive animals.
Therefore, when a plugin decides it needs to really live a life on its own,
one option is for it to create another Java thread. A typical sample is the
following:
new Thread(new Runnable() {
public void run() {
while (true) {
try { Thread.sleep(1000); } catch (Exception e) { }
Display.getDefault().asyncExec(new Runnable() {
public void run() {
... do the real work ...
}
}
}
}
}).start();
This starts a timer that goes off every second and does some work. Because
the work will be done in a unsafe thread, we need to request SWT to perform
the task in a safe manner. We do this by requesting the default SWT display
to run our runnable at a later state using the OS event callback. In
practice this request is served as soon as possible. Execution is performed
asynchronously. In other words, the request is placed in a queue with all
other asyncExec requests and dealt with in a first come, first serve manner.
The call to Display.asyncExec returns immediately, before the actually
drawing takes place. If you need to be garantueed that the changes to the
display to place before continuing, look also at Display.syncExec, which
will suspend execution of the calling thread until the operation has
finished.
Java is not very well equiped to deal with this kind of constructs. There is
no way of avoiding the creation of an (anonymous) inner class. Passing
information from the outer class (such as fields and local variables becomes
cumbersome).
Chris Laffra
"Didier Besset" <didier@ieee.org> wrote in message
news:bi54a8$447$1@eclipse.org...
> Building my first plug-in editor, I am trying to react to resources
> changes. The first level is to refresh the viewers of the editor if the
> file being edited has changed. I did implement a ResourceChangeListener
> and a ResourceDeltaVisitor. However, when time comes to refresh the
> viewers, I get an invalid thread exception because I am not in the thread
> that created the viewer (since being called rfom the workspace, I
> guess...).
>
> Question: how do one refresh the viewers in such case?
>
> Cheers,
>
> Didier
>
|
|
| |
| Re: Propagating resource changes to an editor [message #115087 is a reply to message #114642] |
Fri, 22 August 2003 15:38 |
| Eclipse User |
|
|
|
Originally posted by: wegener.cboenospam.com
Could I suggest a slight change in your example. The real work should be
done prior to passing the runnable to asyncExec(). The asyncExec()
runnable should only update the display. If real work is anything that
takes an appreciable amount of time, the display will become unresponsive.
Chris Laffra wrote:
> When do I call Display.asyncExec?
> Rule of thumb: You never need to calll Display.asyncExec(), unless SWT
> throws an "invalid thread access" exception at you.
> On most operating systems, drawing to the screen is an operation that needs
> to be synchronized with other draw requests to prevent chaos. A simple OS
> solution for this resource contention problem is by allowing drawing
> operations to occur only in a very special thread. Rather than drawing at
> will, an application sends in a request to the OS for a redraw, and the OS
> will call back the application at a time it deems appropriate. An SWT
> application behaves in the same way.
> When the end-user of your plugin activates a menu or pushes a button, the OS
> will notify SWT, which in turn will call other plugins, that call other
> plugins, until eventually the call-chain ends with you. All these calls are
> made in the same event loop thread. Almost all code in Eclipse behaves this
> way. Normally, no plugin acts on its own, but only reacts to stimuli from
> others. In general, plugins are passive animals.
> Therefore, when a plugin decides it needs to really live a life on its own,
> one option is for it to create another Java thread. A typical sample is the
> following:
> new Thread(new Runnable() {
> public void run() {
> while (true) {
> try { Thread.sleep(1000); } catch (Exception e) { }
... do the real work here ...
> Display.getDefault().asyncExec(new Runnable() {
> public void run() {
> ... do the real work ...
... update the display here ...
> }
> }
> }
> }
> }).start();
> This starts a timer that goes off every second and does some work. Because
> the work will be done in a unsafe thread, we need to request SWT to perform
> the task in a safe manner. We do this by requesting the default SWT display
> to run our runnable at a later state using the OS event callback. In
> practice this request is served as soon as possible. Execution is performed
> asynchronously. In other words, the request is placed in a queue with all
> other asyncExec requests and dealt with in a first come, first serve manner.
> The call to Display.asyncExec returns immediately, before the actually
> drawing takes place. If you need to be garantueed that the changes to the
> display to place before continuing, look also at Display.syncExec, which
> will suspend execution of the calling thread until the operation has
> finished.
> Java is not very well equiped to deal with this kind of constructs. There is
> no way of avoiding the creation of an (anonymous) inner class. Passing
> information from the outer class (such as fields and local variables becomes
> cumbersome).
> Chris Laffra
> "Didier Besset" <didier@ieee.org> wrote in message
> news:bi54a8$447$1@eclipse.org...
> > Building my first plug-in editor, I am trying to react to resources
> > changes. The first level is to refresh the viewers of the editor if the
> > file being edited has changed. I did implement a ResourceChangeListener
> > and a ResourceDeltaVisitor. However, when time comes to refresh the
> > viewers, I get an invalid thread exception because I am not in the thread
> > that created the viewer (since being called rfom the workspace, I
> > guess...).
> >
> > Question: how do one refresh the viewers in such case?
> >
> > Cheers,
> >
> > Didier
> >
|
|
| |
Goto Forum:
Current Time: Tue Jul 22 07:43:11 EDT 2025
Powered by FUDForum. Page generated in 0.06391 seconds |
Home