UI not responding

[sprayer]

I have a UI thread not responding also.

I have an Async operation that I am processing a long running SQL script
in ADO.Net. I am executing the Command asynchronous and hooking the
SqlCommand.Stat ementCompleted. I then use AsyncOperation to post events
back to the UI thread. The UI thread then updates a progress bar and
multi-line textbox. I then send a Windows Message to auto scroll the
textbox to the bottom. When the script stops running the UI comes back
to life.

The problem:
Sometimes when the user scrolls the textbox the UI thread locks-up.

What I’ve tried:
I have done extensive testing on my Async class on the execution path,
events and the logic.
The trace statements show the events firing, and being fully handled.
I tried commenting out the auto scroll, but that did not fix it.

What I think the problem is:
Honestly I don’t know.
The trace statements show everything is working correctly and executing
on the correct thread.

Is it possible to overload the application with too many events so the
UI can’t update?

The size of the project makes it very difficult in posting some examples
(Main form 900loc, SQL processor 800loc & Async base 500loc). So I am
just looking for some ideas on how to fix this problem.

Thanks
sprayer

*** Sent via Developersdex http://www.developersdex.com ***

[sdbillsfan]

My advice is to create a small app and attempt to recreate the issue.
It doesn't sound like it would be too difficult and it would make it
much easier for us (you included) to diagnose the problem.
sprayer wrote:

I have a UI thread not responding also.

I have an Async operation that I am processing a long running SQL script
in ADO.Net. I am executing the Command asynchronous and hooking the
SqlCommand.Stat ementCompleted. I then use AsyncOperation to post events
back to the UI thread. The UI thread then updates a progress bar and
multi-line textbox. I then send a Windows Message to auto scroll the
textbox to the bottom. When the script stops running the UI comes back
to life.

The problem:
Sometimes when the user scrolls the textbox the UI thread locks-up.

What I've tried:
I have done extensive testing on my Async class on the execution path,
events and the logic.
The trace statements show the events firing, and being fully handled.
I tried commenting out the auto scroll, but that did not fix it.

What I think the problem is:
Honestly I don't know.
The trace statements show everything is working correctly and executing
on the correct thread.

Is it possible to overload the application with too many events so the
UI can't update?

The size of the project makes it very difficult in posting some examples
(Main form 900loc, SQL processor 800loc & Async base 500loc). So I am
just looking for some ideas on how to fix this problem.

Thanks
sprayer

*** Sent via Developersdex http://www.developersdex.com ***

[sprayer]

Ya am able to reproduce the freeze regularly now. I made a SQL script
that affects ~8000 rows individually. This produced 8000 events to be
raised back to the main UI thread to handle (This is an extreme case,
but it reproduces the error). So I am sending so many events back to
the main UI thread its bogging it down.

What is the best practice for high throughput & chatty asynchronous
process?

I’m using “System.Compone ntModel.AsyncOp eration.Post()” to raise the
events on the UI thread. So I am thinking to not use AsyncOperation and
post the event on the asynchronous thread and then switch to the UI
thread only to update the user controls. Not sure but I think I will
have the same problem.

Thanks for the reply
sprayer
MCAD.NET
*** Sent via Developersdex http://www.developersdex.com ***

[Marc Gravell]

A trick you can use here is to batch the updates at the UI; set a timer
going when you start the async work, and stop it when it completes; when you
get the events, chuck the "updates" (in some form) into a collection
(remembering to lock it first); when the (slower) timer-tick fires [on the
UI thread], lock the same collection and read the "updates" into an array,
then clear the collection and unlock it; (this allows the events to keep
going while you update the UI); now loop through the collection of "updates"
and fix the UI, ideally using BeginUpdate/EndUpdate, SuspendLayout and
ResumeLayout to maximise throughput.

Oh - and remember a final sweep of the collection after stopping the timer
(after the async has ended).

That any help?

Marc

[Marc Gravell]

oh - and by "updates" I meant the vague term of whatever it is you need to
know... perhaps the specific event-type, sender and event-args on a holding
class?

Marc

[sdbillsfan]

The best practice is to increase the interval at which you report
progress. Does your client really need to know when .01% of the work is
done? Probably not.

sprayer wrote:

Ya am able to reproduce the freeze regularly now. I made a SQL script
that affects ~8000 rows individually. This produced 8000 events to be
raised back to the main UI thread to handle (This is an extreme case,
but it reproduces the error). So I am sending so many events back to
the main UI thread its bogging it down.

What is the best practice for high throughput & chatty asynchronous
process?

I'm using "System.Compone ntModel.AsyncOp eration.Post()" to raise the
events on the UI thread. So I am thinking to not use AsyncOperation and
post the event on the asynchronous thread and then switch to the UI
thread only to update the user controls. Not sure but I think I will
have the same problem.

Thanks for the reply
sprayer
MCAD.NET
*** Sent via Developersdex http://www.developersdex.com ***

[Willy Denoyette [MVP]]

If you run a task that updates the UI at such a high frequency, there is no
reason to run it on a separate thread, unless you run this on a SMP or
multi-core. Just run the task on the UI thread, this saves you from burning
a mass of CPU cycles only to marshal the update to the UI thread.

Willy.

"sprayer" <an*******@devd ex.com> wrote in message
news:%2******** ********@TK2MSF TNGP03.phx.gbl. ..
| Ya am able to reproduce the freeze regularly now. I made a SQL script
| that affects ~8000 rows individually. This produced 8000 events to be
| raised back to the main UI thread to handle (This is an extreme case,
| but it reproduces the error). So I am sending so many events back to
| the main UI thread its bogging it down.
|
| What is the best practice for high throughput & chatty asynchronous
| process?
|
| I'm using "System.Compone ntModel.AsyncOp eration.Post()" to raise the
| events on the UI thread. So I am thinking to not use AsyncOperation and
| post the event on the asynchronous thread and then switch to the UI
| thread only to update the user controls. Not sure but I think I will
| have the same problem.
|
| Thanks for the reply
| sprayer
| MCAD.NET
|
|
| *** Sent via Developersdex http://www.developersdex.com ***