WaitCursor behavior

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

When wait cursor is set (via Cursor.Current = Cursors.WaitCursor) user is
still able to interact with the form.
Such a behavior can lead to unpredictable results (errors). So is there any
pattern to avoid interation between user and form while using WaitCursor?

P.S. Currently I use Enable/Disable all the controls technic, but it takes
some tiem to Enable/Disable controls which is not good. Also it is not a
common practice for the Windows Mobile application.
 
Microsoft recommends the WaitCursor to be shown when the UI is performing
some synchronous processing which renders the UI unresponsive for more than
0.5 seconds.
So during this time, the UI will not respond to events if processing
synchronously.

If you are processing asynchronously, you need to design your application
accordingly so that the process can be canceled by the user.

Simon.
 
Yes, I'm talking about async processing operations.
Yes, I need to let user abort the operation in case of process has stucked
on async operation.

What I was asking is: Is there any better (from point of user experiance /
UI design) way to block form while performing async operations?
 
Firstly you did not tell us you were processing asynchronously, you fact you
are using the WaitCursor leads the group to think you are processing
synchronously. Secondly you didn't tell us you needed or had designed it so
you could cancel processing.

Generally the WaitCursor should only be used when processing synchronously -
check out Microsoft Device guidelines on MSDN.

There is no magic property to set which stops a user from interacting with
the UI during async processing, you have to code it yourself. What I tend to
do on long processing is have a separate frame which displays a progress bar
along with a cancel button. Also if the user tries to close the form, I
check if the thread is running, if so give the user an option to quit etc.

Simon.
 
First of all, thanks for your pattern.

I guess I need to add one more point to my previous message. All async
processing I'm talking about are async requests to the server and basicly it
takes from 0.5 to 1 second to perform the request, get answer, and invoke
appropriate logic on the client.

I use much the same pattern as you've described when it takes more then 2
seconds to perform an async operation. But I don't think its a good idea to
use such a pattern for operations with duration less than a second. Have you
heared about any patterns different from the one you've described and the one
I've described in my previous post?
 
If the process only takes a maximum of 1 second why are you using
multi-threading?

Simon.
 
As I wrote in previous post application performs async requests to the server
(using sockets). Application itself is designed to use server through Wi-Fi
network so that user work in real-time with real data and had no need to sync
local and global databases. This approach reduces amount of incorrect or
rejected data when synchronizing with the server database.
So it is not a multithreading, it's more like async convesation with the
server.
 
Back
Top