Setting Wait cursor without a reference to main form.

  • Thread starter Thread starter info
  • Start date Start date
I

info

Hi All,

I am trying to set the hourglass cursor inside a class that has nothing
to do with MainForm class and I don't want to pass a reference to
MainForm.

How can I set the current cursor to Hourglass and then back to arrow?

Thanks a lot,

Alberto
 
Hi Alberto,

You can use the Application.UseWaitCursor property in the 2.0 framework.
 
You can use the Application.UseWaitCursor property in the 2.0 framework.

Right, or use Cursor.Current for a global setting.


Oliver Sturm
 
Hello Dave,
Well, there's a subtle difference:

"Setting the Current property changes the cursor currently displayed. The
application may or may not continue to listen for mouse events. To signal
that the application should not respond to mouse events during a
long-running operation, use the UseWaitCursor property."
Click to expand...

Yeah... as far as I know (from reading through Reflector generated code,
IIRC), there's no real behavioural difference though. In practice, the
setting in Cursor.Current seems to be overridden by that in each single
control (which makes sense - no idea whether it's defined to work like
that anywhere), and the UseWaitCursor property basically sets a special
control style on all the controls in an application recursively. So that
would be the major difference, and I agree it's a good idea to use that
property for the particular purpose. I mentioned Cursor.Current as a more
general way of setting the mouse cursor, which would, for instance, also
allow to set other cursors.


Oliver Sturm
 
Hi Oliver,

Actually, they don't have the same behavior at all.

Cursor.Current can be used while the UI thread is not processing messages.
As soon the UI thread begins processing messages again the Current property
is reset automatically.

Application.UseWaitCursor persists even while the UI thread processes
messages but requires initialization time to update all of the Forms and
Controls.

Neither setting actually prevents user input, though. Since the
Cursor.Current property is used while the UI thread isn't processing
messages it may be perceived as blocking user input.
Application.UseWaitCursor just sets the cursor globally and must be set to
false explicitly in order to be reset, but it signals to end-users that the
application shouldn't be used even though it may be responsive.
 
Hello Dave,
Actually, they don't have the same behavior at all.
Click to expand...

Depends on your view point - both switch the cursor to the wait cursor
when set accordingly, which classifies as "same behaviour" for me. Of
course I agree that because they use different approaches to do this, they
end up behaving differently depending on the situation.
Cursor.Current can be used while the UI thread is not processing messages.
As soon the UI thread begins processing messages again the Current
property is reset automatically.
Click to expand...

Yes, that is interesting. I think I have observed this, but thought
nothing of it apart from "it doesn't always work correctly". Do you know
whether it's intended to work like that? Doesn't seem to make much sense
to me as intended behaviour...
Application.UseWaitCursor persists even while the UI thread processes
messages but requires initialization time to update all of the Forms and
Controls.
Click to expand...

True, of course. Maybe that is the context where the behaviour of
Cursor.Current makes sense - either switch the cursor quick and dirty, or
do it thoroughly, but at a cost.
Neither setting actually prevents user input, though.
Click to expand...

Yes, of course not. Important to mention.
... but it signals to end-users that the application shouldn't be used
even though it may be responsive.
Click to expand...

Well, that part is a problem if you ask me - it may be that that's what's
supposed to be signalled to the end-user, but as a developer I would never
depend on it. In the end I'll have to take other measures to make sure my
application actually *can't* be used when I don't want it to, and then
it's more correct to say "... it signals to end-users that the application
can't be used and that it may not be responsive."


Oliver Sturm
 
Hi Oliver,

Yes, that is interesting. I think I have observed this, but thought
nothing of it apart from "it doesn't always work correctly". Do you know
whether it's intended to work like that? Doesn't seem to make much sense
to me as intended behaviour...
Click to expand...

Since Controls handle the display of the cursor when the mouse is in their
display area, it wouldn't make much sense to be able to override that
functionality through the Cursor property, so I believe that this behavior
is intentional (and I think this behavior comes from the Win32 API
functions). Application.UseWaitCursor was, I presume, added so that
Controls' cursors could be changed globally, overriding the default Control
behavior.
True, of course. Maybe that is the context where the behaviour of
Cursor.Current makes sense - either switch the cursor quick and dirty, or
do it thoroughly, but at a cost.
Click to expand...

I think Application.UseWaitCursor is intended for applications that execute
long-running processes on a background-thread, so the application can be
responsive but the user is aware that some important process is still
running.

Cursor.Current makes sense if you're going to block the UI thread, which
isn't recommended in the first place, of course :)

Well, that part is a problem if you ask me - it may be that that's what's
supposed to be signalled to the end-user, but as a developer I would never
depend on it. In the end I'll have to take other measures to make sure my
application actually *can't* be used when I don't want it to, and then
it's more correct to say "... it signals to end-users that the application
can't be used and that it may not be responsive."
Click to expand...

You can use Application.UseWaitCursor to let end-users know that your
application is busy on a background-thread without preventing them from
doing other things.
 
Hello Dave,
Cursor.Current makes sense if you're going to block the UI thread, which
isn't recommended in the first place, of course :)
Click to expand...

Right, that's what I meant when I said it doesn't make too much sense to me.
You can use Application.UseWaitCursor to let end-users know that your
application is busy on a background-thread without preventing them from
doing other things.
Click to expand...

Then again, if my application is written in such a way that my UI is
actually responsive, and it makes sense to do something in it, I wouldn't
switch the cursor to a wait cursor. Basically, Windows has just one mouse
cursor... to switch it to a wait cursor for a certain application or
window should mean that this application or window is not available for
interaction, IMO. IOW, I can't expect the user to notice that the UI is
actually active when I'm displaying a wait cursor. I'm sure we don't
disagree here - just for the sake of completeness.


Oliver Sturm
 
Hi Oliver,

Yes, I agree, but I've seen UseWaitCursor used in responsive applications.
It's not usually the best design, IMO. A status bar is much better.

However, there are cases where the UI is only partially interactive, in
which case UseWaitCursor might make sense.
 
Hello Dave,
However, there are cases where the UI is only partially interactive, in
which case UseWaitCursor might make sense.
Click to expand...

Right - we've been talking about the Application.UseWaitCursor property
the whole time. It's worth mentioning that the property is also available
on the Control class. Used on a control instance, it sets the wait cursor
for that control and all its children, if any.


Oliver Sturm
 
Back
Top