What's the difference between Cursor = Cursors.WaitCursor and CurrentCursor=Cursors.WaitCursor

J

Just Me

Does Me.Cursor.Current=Cursors.WaitCursor
set the current property of Me.Cursor to Cursors.WaitCursor
And Me.Cursor.Current=Cursors.Default set the Me.Current
property to something (default) stored in Me.Cursor.

Or is Cursors.Default some process wide cursor shape?

What is a correct statement?


I the top statement is correct what happens if I do
Me.Cursor=Cursors.WaitCursor
Me.Cursor=Cursors.Default

Thanks
 
J

Jay B. Harlow [MVP - Outlook]

Just Me,
Assuming your sample code is in a Form.

"Cursor" is both a type (System.Windows.Forms.Cursor)
http://msdn.microsoft.com/library/d...l/frlrfsystemwindowsformscursorclasstopic.asp

and a property (Control.Cursor)
http://msdn.microsoft.com/library/d...systemwindowsformscontrolclasscursortopic.asp


Current is a Shared property of the Cursor type.

http://msdn.microsoft.com/library/d...SystemWindowsFormsCursorClassCurrentTopic.asp


Control.Cursor gets & sets the control's (form's) cursor. Each control can
have a different cursor. Remember that Form inherits (indirectly) from
Control.

Cursor.Current gets & sets the application's cursor. Which can be overriden
by individual forms via Control.Cursor.

Hope this helps
Jay
 
J

Just Me

I'm still confused about Cursors.Default.
What is that?

Thanks for the previous reply
 
J

Jay B. Harlow [MVP - Outlook]

Just Me,
It is the "normal select" mouse pointer defined under Win32 Control Panel.

Normally you only need to set Cursor.Current = Cursors.WaitCursor, once your
event finishes Cursor.Current will revert back to Cursors.Default, as
Application.DoEvents will implicitly have be executed.

Where you need to be careful is if you explicitly call Application.DoEvents
while processing an event. Cursor.Current will revert back to
Cursors.Default. (The remarks under Cursor.Current.)

Remember that .NET looks at the Control.Cursor property under the mouse to
display the cursor, if Control.Cursor = Cursors.Default it will look at
Cursor.Current.

Also remember if you don't explicitly set Control.Cursor it will be set to
the value of its parent, which ultimately will be a Form...

Hope this helps
Jay
 
J

Just Me

That's great

Thanks

"> Where you need to be careful is if you explicitly call
Application.DoEvents
while processing an event. Cursor.Current will revert back to
Cursors.Default. (The remarks under Cursor.Current.)

I had read those remarks and that's when I got confused. How do you handle
that situation if you explicitly call Application.DoEvents?

I suppose in most cases I do know that the cursor should be Wait where I do
Application.DoEvents and could set Cursor.Current to wait there, but that
seems messy.

Suppose I have a library routine that contains an Application.DoEvents!
There I may not know how the Cursor should be set.

Maybe instead of Cursor.Current I could set Me.Cursor - have to think about
that.
 
J

Jay B. Harlow [MVP - Outlook]

Just Me,
I had read those remarks and that's when I got confused. How do you handle
that situation if you explicitly call Application.DoEvents?
I rarely call Application.DoEvents! Instead I (normally) rely on threading
for long running tasks.
Suppose I have a library routine that contains an Application.DoEvents!
There I may not know how the Cursor should be set.
You could save the current Cursor.Current before you call
Application.DoEvents, then restore it when you are done. Something like:

Dim current As Cursor = Cursor.Current
Application.DoEvents()
Cursor.Current = current

Alternatively you could set Me.Cursor.
Maybe instead of Cursor.Current I could set Me.Cursor - have to think
about that.
The problem with Me.Cursor is that you need to remember to set it back, for
example if an exception occurred! Plus if you ever change Me.Cursor in the
forms designer, every place you set it back would need to change!

I prefer setting Cursor.Current as it can occur anyplace, and the system
will automatically set it back to an arrow for me.

Hope this helps
Jay
 
J

Just Me

Thanks, especially telling what you prefer since it displays an experienced
decision that I can use until I feel confident.
 
J

Jay B. Harlow [MVP - Outlook]

Just Me,
I should add I have one app where I set Control.Cursor based on the
MouseMove event.

Its a custom control, the control is partitioned into a grid (similar to a
chess board) if the mouse moves over a square that is "occupied" I set
Me.Cursor to Cursors.Hand if the square is not occupied I set Me.Cursor to
Cursors.Arrow. Using Cursor.Current in this instance won't work as
Cursor.Current stops listening to the Mouse...

I prefer to use Cursor.Current for actions that I need to use
Cursors.WaitCursor, such as File Save that is normally short enough not to
use a thread...

Hope this helps
Jay
 
J

Just Me

Thanks for all the input.
At first I didn't like the fact that cursor.current might get set back to
Cursors.Default but now I like the idea. I have had programs get stuck with
the wait symbol (maybe because of an error of cancel) which would be
unlikely with cursor.current

Thanks again
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top