Setting Wait cursor without a reference to main form.

[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

[Dave Sexton]

Hi Alberto,

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

--
Dave Sexton

<in**@devdept.comwrote in message
news:11**********************@j72g2000cwa.googlegr oups.com...

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

[Oliver Sturm]

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

Right, or use Cursor.Current for a global setting.
Oliver Sturm
--
http://www.sturmnet.org/blog

[Dave Sexton]

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/lib...r.current.aspx

--
Dave Sexton

"Oliver Sturm" <ol****@sturmnet.orgwrote in message
news:xn****************@msnews.microsoft.com...

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

Right, or use Cursor.Current for a global setting.
Oliver Sturm
--
http://www.sturmnet.org/blog

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

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
--
http://www.sturmnet.org/blog

[Dave Sexton]

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.

--
Dave Sexton

"Oliver Sturm" <ol****@sturmnet.orgwrote in message
news:xn****************@msnews.microsoft.com...

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

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
--
http://www.sturmnet.org/blog

[Oliver Sturm]

Hello Dave,

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

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.

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.

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.

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.

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
--
http://www.sturmnet.org/blog

[Dave Sexton]

Hi Oliver,

<snip>

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

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

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.

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

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.

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>

>>... but it signals to end-users that the application shouldn't be used
even though it may be responsive.

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

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.

--
Dave Sexton

[Oliver Sturm]

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

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.

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
--
http://www.sturmnet.org/blog

[Dave Sexton]

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.

--
Dave Sexton

"Oliver Sturm" <ol****@sturmnet.orgwrote in message
news:xn****************@msnews.microsoft.com...

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

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.

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
--
http://www.sturmnet.org/blog

[Oliver Sturm]

Hello Dave,

>However, there are cases where the UI is only partially interactive, in
which case UseWaitCursor might make sense.

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
--
http://www.sturmnet.org/blog

[info]

Thanks a lot guys!

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

Alberto

Oliver Sturm wrote:

Hello Dave,

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

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
--
http://www.sturmnet.org/blog

[Oliver Sturm]

>Thanks a lot guys!

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

Hehe... some good coming off such a discussion :-)
Oliver Sturm
--
http://www.sturmnet.org/blog