Long activity indicator control

[nano2k]

Hi

I have a winforms application developed in c# v1.1.
The application has a form that calls a webservice method. The call is
performed from inside the GUI thread and may take up to a minute.
Meanwhile, I want to provide to the user some sort of visual indicator
indicating that the application is not frozen.
The call to the WS should remain on the GUI thread, as I don't want
the user to manipulate other visual controls while the call is in
effect.
I don't need to display a progress bar, just some sort of a dynamic
image like this:
https://marketplace.slizone.com/SliMarketplace/Images/loading.gif
or another user control that plays some dynamic content.
Any idea how to perform this?
Thanks.

 

[Jon Skeet [C# MVP]]

I have a winforms application developed in c# v1.1.
The application has a form that calls a webservice method. The call is
performed from inside the GUI thread and may take up to a minute.

Doing that on a GUI thread is not a good idea.

Meanwhile, I want to provide to the user some sort of visual indicator
indicating that the application is not frozen.
The call to the WS should remain on the GUI thread, as I don't want
the user to manipulate other visual controls while the call is in
effect.

Then disable those controls while the operation is in progress. You
shouldn't make a long-running call on the UI thread.

I don't need to display a progress bar, just some sort of a dynamic
image like this:https://marketplace.slizone.com/SliMarketplace/Images/loading.gif
or another user control that plays some dynamic content.
Any idea how to perform this?

I would seriously look at disabling all controls on the UI thread, and
then making the call elsewhere, updating the UI with a progress
indicator (of any kind, whether that's an image or not) appropriately.

I know it's a pain, but locking up the UI thread for a minute is a
really bad idea.

Jon

 

[Guest]

As an add-on to what Jon indicated (good advice), you can put an animated gif
into a picturebox control and turn on the Visible property when the call is
made. When results come back, you make the pic invisible. But you do not want
to make your webservice call from the UI thread.
-- Peter
http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder: http://www.blogmetafinder.com

 

[nano2k]

Doing that on a GUI thread is not a good idea.


Then disable those controls while the operation is in progress. You
shouldn't make a long-running call on the UI thread.


I would seriously look at disabling all controls on the UI thread, and
then making the call elsewhere, updating the UI with a progress
indicator (of any kind, whether that's an image or not) appropriately.

I know it's a pain, but locking up the UI thread for a minute is a
really bad idea.

Jon

Hi
Thanks
Why is it such a bad idea? The only bad side I see is that the GUI
won't get painted while the call is in progress.
Actually, in 99% of the times, the call will not take more than a
second (it only authenticates the user), but, say, when the WS is
offline, the call will take long enough until the exception pops up,
so the call deserves some sort of visual signal to the user.
Isn't there a method of forcing a portion of the GUI to update from
another thread?
Tried this from another thread (using Invoke(), of course), but no
luck.

Thanks again.

 

[nano2k]

As an add-on to what Jon indicated (good advice), you can put an animatedgif
into a picturebox control and turn on the Visible property when the call is
made. When results come back, you make the pic invisible. But you do not want
to make your webservice call from the UI thread.
-- Peterhttp://www.eggheadcafe.com
unBlog:http://petesbloggerama.blogspot.com
BlogMetaFinder: http://www.blogmetafinder.com






- Afi are text în citat -

Peter, Jon, thanks.
I understand that calling WS methods from withing GUI thread is
undesirable.
I aggree with you both.
Peter, I already put an animated GIF on the form, using a picture box,
but the GIF gets frozen, too.
My problem is that the authentication call is only an example. The
form may call many other WS methods, so it's practically impossible
for me to put them on a separate thread.
I'm still looking for a workaround for this problem, being determined
not to make the same mistake twice.
Thanks.

 

[BlueTrin]

Peter, Jon, thanks.
I understand that calling WS methods from withing GUI thread is
undesirable.
I aggree with you both.
Peter, I already put an animated GIF on the form, using a picture box,
but the GIF gets frozen, too.
My problem is that the authentication call is only an example. The
form may call many other WS methods, so it's practically impossible
for me to put them on a separate thread.
I'm still looking for a workaround for this problem, being determined
not to make the same mistake twice.
Thanks.

Can't you just use a modal form on another thread ?

 

[Christof Nordiek]

Hi
Thanks
Why is it such a bad idea? The only bad side I see is that the GUI
won't get painted while the call is in progress.

What is bad enough. Besides, that the application appears to hang and may be
blanked out, also your indicator will appear frozen (or not at all).

Isn't there a method of forcing a portion of the GUI to update from
another thread?
Tried this from another thread (using Invoke(), of course), but no
luck.

That's, because Invoke pushes the task to the GUI-Thread, and the Invoked
method will not run, before the long call on the GUI-Thread is finished.
Besides, this also blocks the calling Invoke.

Christof

 

[nano2k]

Can't you just use a modal form on another thread ?- Ascunde citatul -

- Afi are text în citat -

Thanks, I'll try that.

 

[Chris Shepherd]

Peter, Jon, thanks.
I understand that calling WS methods from withing GUI thread is
undesirable.
I aggree with you both.
Peter, I already put an animated GIF on the form, using a picture box,
but the GIF gets frozen, too.

This would be because the UI thread is blocked waiting for the WS call
to return.

My problem is that the authentication call is only an example. The
form may call many other WS methods, so it's practically impossible
for me to put them on a separate thread.

What difficulty are you having in pushing your functionality to another
thread that makes it "practically impossible" to do so?



Chris.

 

[nano2k]

This would be because the UI thread is blocked waiting for the WS call
to return.

Yes.



What difficulty are you having in pushing your functionality to another
thread that makes it "practically impossible" to do so?

There are few tens of web methods that are called by the client
winform application.
Moving all the calls to another thread can induce some bugs. The
application is already deployed to many customers and works online day
and night. At this moment, I couldn't assume even a minimum risc of
inducing a subtle bug. Plus, the time is limited.
So, the reasons are more non-technical than technical. Maybe in a
future release, when the time won't be such a painful thought, I could
take the luxury to redesign this part, because, believe me, I need to
redesign some other related pieces of code.
For now, I am looking for a simple solution, if one exists.
I'll get back when I find one.

Thanks all.

 

[Ian Semmel]

Don't you get frustrated when windows freeze on the screen, won't
respond to anything and display 'Not Responding'.

In programming, it is actually the 1% that involves most of the work.