Eclipse Community Forums: Eclipse Platform » Progress Monitor threading leads to undesired code execution order

Home » Eclipse Projects » Eclipse Platform » Progress Monitor threading leads to undesired code execution order

Progress Monitor threading leads to undesired code execution order [message #296207]

Fri, 16 December 2005 14:29

Eclipse User

What is the correct way to handle this situation?

1. CellEditor in a TableViewer is active.
2. User takes action which results in an event which causes the
focusLost() to be triggered on the active CellEditor.
3. The CellEditor#modify method spawns a progress monitor in a separate
thread.
4. The action triggering the focusLost() event is then processed while the
progress monitor is working.
5. The rest of the CellEditor#modify method is executed.

I'd like step 5 to occur prior to step 4. So far the fix has been to
filter out other events until the progress monitor completes.

Re: Progress Monitor threading leads to undesired code execution order [message #296488 is a reply to message #296207]

Thu, 22 December 2005 16:23

Eclipse User

Originally posted by: nick_edgar._no.spam.please_.ca.ibm.com

Eli,

Sorry for the delay. I looked for your post earlier, but must have
missed it.

The problem is that most progress monitor implementations spin the event
loop while waiting for the operation to complete, in order to keep the
UI responsive.

Which progress monitor are you using? Does the UI need to be responsive
during your operation?

Nick

Eli Groesbeck wrote:
> What is the correct way to handle this situation?
>
> 1. CellEditor in a TableViewer is active.
> 2. User takes action which results in an event which causes the
> focusLost() to be triggered on the active CellEditor.
> 3. The CellEditor#modify method spawns a progress monitor in a separate
> thread.
> 4. The action triggering the focusLost() event is then processed while
> the progress monitor is working.
> 5. The rest of the CellEditor#modify method is executed.
>
> I'd like step 5 to occur prior to step 4. So far the fix has been to
> filter out other events until the progress monitor completes.

Re: Progress Monitor threading leads to undesired code execution order [message #296923 is a reply to message #296488]

Wed, 04 January 2006 15:08

Eclipse User

I'm using the ProgressMonitorPart as used in the JFace Wizard framework. I
was able to get the desired behavior by overriding the WizardDialog#run
method to spawn a thread to run the operation and the UI thread waits until
the new thread returns. The culprit in this case was the ModalContextThread
which was spinning through the event loop.

"Nick Edgar" <nick_edgar@_no.spam.please_.ca.ibm.com> wrote in message
news:dof5g5$h0o$1@utils.eclipse.org...
> Eli,
>
> Sorry for the delay. I looked for your post earlier, but must have missed
> it.
>
> The problem is that most progress monitor implementations spin the event
> loop while waiting for the operation to complete, in order to keep the UI
> responsive.
>
> Which progress monitor are you using? Does the UI need to be responsive
> during your operation?
>
> Nick
>
> Eli Groesbeck wrote:
>> What is the correct way to handle this situation?
>>
>> 1. CellEditor in a TableViewer is active.
>> 2. User takes action which results in an event which causes the
>> focusLost() to be triggered on the active CellEditor.
>> 3. The CellEditor#modify method spawns a progress monitor in a separate
>> thread.
>> 4. The action triggering the focusLost() event is then processed while
>> the progress monitor is working.
>> 5. The rest of the CellEditor#modify method is executed.
>>
>> I'd like step 5 to occur prior to step 4. So far the fix has been to
>> filter out other events until the progress monitor completes.

Re: Progress Monitor threading leads to undesired code execution order [message #296947 is a reply to message #296923]

Thu, 05 January 2006 10:48

Eclipse User

Originally posted by: nick_edgar._no.spam.please_.ca.ibm.com

Why even bother spawning a thread in this case? If the UI thread is
blocked until the thread terminates, why not just do the work in the UI
thread?

In either case, how do you report progress, and get the UI to update the
shown progress without spinning the event loop?

Nick

exquisitus wrote:
> I'm using the ProgressMonitorPart as used in the JFace Wizard framework. I
> was able to get the desired behavior by overriding the WizardDialog#run
> method to spawn a thread to run the operation and the UI thread waits until
> the new thread returns. The culprit in this case was the ModalContextThread
> which was spinning through the event loop.
>
>
> "Nick Edgar" <nick_edgar@_no.spam.please_.ca.ibm.com> wrote in message
> news:dof5g5$h0o$1@utils.eclipse.org...
>
>>Eli,
>>
>>Sorry for the delay. I looked for your post earlier, but must have missed
>>it.
>>
>>The problem is that most progress monitor implementations spin the event
>>loop while waiting for the operation to complete, in order to keep the UI
>>responsive.
>>
>>Which progress monitor are you using? Does the UI need to be responsive
>>during your operation?
>>
>>Nick
>>
>>Eli Groesbeck wrote:
>>
>>>What is the correct way to handle this situation?
>>>
>>>1. CellEditor in a TableViewer is active.
>>>2. User takes action which results in an event which causes the
>>>focusLost() to be triggered on the active CellEditor.
>>>3. The CellEditor#modify method spawns a progress monitor in a separate
>>>thread.
>>>4. The action triggering the focusLost() event is then processed while
>>>the progress monitor is working.
>>>5. The rest of the CellEditor#modify method is executed.
>>>
>>>I'd like step 5 to occur prior to step 4. So far the fix has been to
>>>filter out other events until the progress monitor completes.
>
>
>

Re: Progress Monitor threading leads to undesired code execution order [message #296948 is a reply to message #296947]

Thu, 05 January 2006 10:52

Eclipse User

Originally posted by: richkulp.us.NO_SPAM.ibm.com

The reason you use another thread is because when the UI thread is
blocked it looks really bad to a user. Nothing is repainted. If you
cover the window and show it again it is left unpainted.

The progress monitor allows you to show progress during the whole time
the other thread is running. So the other thread can say it's 50%
complete and the progress monitor will move to 50%. If you were running
on the UI thread the monitor would never get a chance to paint and say this.

Nick Edgar wrote:
> Why even bother spawning a thread in this case? If the UI thread is
> blocked until the thread terminates, why not just do the work in the UI
> thread?
>
> In either case, how do you report progress, and get the UI to update the
> shown progress without spinning the event loop?
>
> Nick
>
> exquisitus wrote:
>
>> I'm using the ProgressMonitorPart as used in the JFace Wizard
>> framework. I was able to get the desired behavior by overriding the
>> WizardDialog#run method to spawn a thread to run the operation and the
>> UI thread waits until the new thread returns. The culprit in this
>> case was the ModalContextThread which was spinning through the event
>> loop.
>>
>>
>> "Nick Edgar" <nick_edgar@_no.spam.please_.ca.ibm.com> wrote in message
>> news:dof5g5$h0o$1@utils.eclipse.org...
>>
>>> Eli,
>>>
>>> Sorry for the delay. I looked for your post earlier, but must have
>>> missed it.
>>>
>>> The problem is that most progress monitor implementations spin the
>>> event loop while waiting for the operation to complete, in order to
>>> keep the UI responsive.
>>>
>>> Which progress monitor are you using? Does the UI need to be
>>> responsive during your operation?
>>>
>>> Nick
>>>
>>> Eli Groesbeck wrote:
>>>
>>>> What is the correct way to handle this situation?
>>>>
>>>> 1. CellEditor in a TableViewer is active.
>>>> 2. User takes action which results in an event which causes the
>>>> focusLost() to be triggered on the active CellEditor.
>>>> 3. The CellEditor#modify method spawns a progress monitor in a
>>>> separate thread.
>>>> 4. The action triggering the focusLost() event is then processed
>>>> while the progress monitor is working.
>>>> 5. The rest of the CellEditor#modify method is executed.
>>>>
>>>> I'd like step 5 to occur prior to step 4. So far the fix has been
>>>> to filter out other events until the progress monitor completes.
>>
>>
>>
>>

--
Thanks,
Rich Kulp

Re: Progress Monitor threading leads to undesired code execution [message #297002 is a reply to message #296948]

Fri, 06 January 2006 09:56

Eclipse User

So it sounds like you are actually processing UI events?

Re: Progress Monitor threading leads to undesired code execution [message #297036 is a reply to message #297002]

Fri, 06 January 2006 13:04

Eclipse User

Originally posted by: richkulp.us.NO_SPAM.ibm.com

Yes. The Progress monitor simply spins on the UI thread. The other
shells of the application have been disabled. So they will still paint
but you can't click on them. So that way you other thread can process
while the UI thread is still being handled and painting done.

Nick Edgar wrote:
> So it sounds like you are actually processing UI events?

--
Thanks,
Rich Kulp

Re: Progress Monitor threading leads to undesired code execution [message #297051 is a reply to message #297036]

Fri, 06 January 2006 14:19

Eclipse User

So it seems like this won't solve the original problem.
Since events are being processed, his step 4 will still occur before step 5.

Re: Progress Monitor threading leads to undesired code execution [message #297061 is a reply to message #297051]

Fri, 06 January 2006 17:44

Eclipse User

The UI thread is looping until the other thread completes. Inside the UI
loop the progress monitor is updated manually. As long as
Display#readAndDispatch isn't called the correct order will occur.

"Nick Edgar" <nick_edgar@ca.ibm.com> wrote in message
news:14740232.1136575204702.JavaMail.root@cp1.javalobby.org...
> So it seems like this won't solve the original problem.
> Since events are being processed, his step 4 will still occur before step
> 5.

Re: Progress Monitor threading leads to undesired code execution [message #297066 is a reply to message #297061]

Fri, 06 January 2006 18:49

Eclipse User

Originally posted by: richkulp.us.NO_SPAM.ibm.com

But then you run into the problem that nothing paints and the progress
monitor won't advance. In that case you might as well just run in line
without invoking a progress monitor.

Eli Groesbeck wrote:
> The UI thread is looping until the other thread completes. Inside the UI
> loop the progress monitor is updated manually. As long as
> Display#readAndDispatch isn't called the correct order will occur.
>
> "Nick Edgar" <nick_edgar@ca.ibm.com> wrote in message
> news:14740232.1136575204702.JavaMail.root@cp1.javalobby.org...
>
>>So it seems like this won't solve the original problem.
>>Since events are being processed, his step 4 will still occur before step
>>5.
>
>
>

--
Thanks,
Rich Kulp

Re: Progress Monitor threading leads to undesired code execution [message #297426 is a reply to message #297066]

Fri, 13 January 2006 09:55

Eclipse User

It does paint, you have to manually set the progress in the UI loop that is
waiting on the other thread to complete. So rather than using the
inderterminate progress indicator you have to set the progress as a
percentage and keep resetting it at 100.

"Rich Kulp" <richkulp@us.NO_SPAM.ibm.com> wrote in message
news:dpmvms$7rh$1@utils.eclipse.org...
> But then you run into the problem that nothing paints and the progress
> monitor won't advance. In that case you might as well just run in line
> without invoking a progress monitor.
>
> Eli Groesbeck wrote:
>> The UI thread is looping until the other thread completes. Inside the UI
>> loop the progress monitor is updated manually. As long as
>> Display#readAndDispatch isn't called the correct order will occur.
>>
>> "Nick Edgar" <nick_edgar@ca.ibm.com> wrote in message
>> news:14740232.1136575204702.JavaMail.root@cp1.javalobby.org...
>>
>>>So it seems like this won't solve the original problem.
>>>Since events are being processed, his step 4 will still occur before step
>>>5.
>>
>>
>>
>
> --
> Thanks,
> Rich Kulp

Previous Topic:	3.2 M4 - org.eclipse.core.commands.common.EventManager cannot be resolved
Next Topic:	TableViewer losing its virtualization in a Section

Goto Forum:

-=] Back to Top [=-

Current Time: Tue Jul 22 07:39:17 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter