|Re: Jobs, UIJobs and Threads oh my! [message #520254 is a reply to message #520214]
||Thu, 11 March 2010 16:54
| Steffen Zschaler
Registered: July 2009
When you do a syncExec, your original job should just be waiting for the |
work on the UI thread to be done. Once syncExec returns, you should be
back on the original worker thread. Assuming you are not a UIJob, this
should not be the UI thread. You can store the data from the UI thread
in fields of the runnable handed to syncExec and then retrieve it from
there once syncExec has returned.
On 11/03/2010 15:14, Craig Foote wrote:
> I'm not sure what you mean by "get the UI thread", or why I would want
> to get it.
> Again, I'm in a Job and I can use either of:
> 1. Display.getDefault().asyncExec()
> 2. Display.getDefault().syncExec()
> 3. UIJob
> .. to do the work required to be done on the UI thread. My issue is
> continuing the Job on the worker thread once the UI work is done and
> use the information that was obtained on the UI thread.
> It's kind of the reverse. I'm back in my Job but it's now on the UI
> thread and needs to be back on the worker thread.
> I tried storing the getThread() result in the run() of the Job as an
> instance variable and then in my UIJob's JobChangeListener's done(),
> where I get the UI info and call my Job method, calling:
> ..but it continues to run on the UI thread, seemingly ignoring the call.
Powered by FUDForum
. Page generated in 0.08699 seconds