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.

Show quoteHide quote

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


                Oliver Sturm

Hi Oliver,

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."

Cursor.Current Property
§ Remarks
http://msdn2.microsoft.com/en-us/library/system.windows.forms.cursor.current.aspx

Show quoteHide quote

Hello Dave,

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.

Show quoteHide quote

Hello Dave,

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.

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...

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.

Yes, of course not. Important to mention.

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,

<snip>

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.

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 :)

<snip>

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,

Right, that's what I meant when I said it doesn't make too much sense to me.

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.

Show quoteHide quote

Hello Dave,

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

Thanks a lot guys!

I would have never expected such a detailed list of answers...

Alberto

Oliver Sturm wrote:
Show quoteHide quote

Hehe... some good coming off such a discussion :-)


                Oliver Sturm

Bugs, bugs ...
How to avoid redundant case statements in a stored procedure
Handling of different return code correspondingly in a stored procedure
nvarchar vs varchar in .net application
Optimal Workstation for Visual Studio .NET 2003 and 2005