472,143 Members | 1,334 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,143 software developers and data experts.

Confused obout setting a Cursor

What are the different effects of the following two statements:

C1.Cursor = Cursors.WaitCursor

C1.Cursor.Current = Cursors.WaitCursor

I believe the first replaces the entire C1.Cursor object with a new one
while the second only replaces the Current object of C1.Cursor, but I can't
figure when to use which.

Thanks for any help!
Nov 4 '06 #1
7 6062
Hi,

If C1 is an instance of a Control:
C1.Cursor = Cursors.WaitCursor
This will set the cursor to be the Window's WaitCursor (usually an hour glass)
when the mouse is within the boundaries of the Control and any of its children
C1.Cursor.Current = Cursors.WaitCursor
This will not compile in C#. Cursor.Current is a static property and cannot
be accessed through an instance of a Cursor object. When set, the current
cursor being displayed is supposedly changed, according to the MSDN docs, but
it seems to be reverted back to Cursors.Default immediately in my testing.

--
Dave Sexton

" Academic" <ac************@a-znet.comwrote in message
news:ub**************@TK2MSFTNGP04.phx.gbl...
What are the different effects of the following two statements:

C1.Cursor = Cursors.WaitCursor

C1.Cursor.Current = Cursors.WaitCursor

I believe the first replaces the entire C1.Cursor object with a new one
while the second only replaces the Current object of C1.Cursor, but I can't
figure when to use which.

Thanks for any help!


Nov 4 '06 #2

If you're in some method that will take a while do you set Cursor or
Current?
Just before you leave the method do you reset to Default or is that
automatic?
Thanks for the help
"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:OY**************@TK2MSFTNGP04.phx.gbl...
Hi,

If C1 is an instance of a Control:
>C1.Cursor = Cursors.WaitCursor

This will set the cursor to be the Window's WaitCursor (usually an hour
glass) when the mouse is within the boundaries of the Control and any of
its children
>C1.Cursor.Current = Cursors.WaitCursor

This will not compile in C#. Cursor.Current is a static property and
cannot

bad example. should be

System.Windows.Forms.Cursor.Current

be accessed through an instance of a Cursor object. When set, the current
cursor being displayed is supposedly changed, according to the MSDN docs,
but it seems to be reverted back to Cursors.Default immediately in my
testing.

Before leaving the routine the setting is in?

>
--
Dave Sexton

" Academic" <ac************@a-znet.comwrote in message
news:ub**************@TK2MSFTNGP04.phx.gbl...
>What are the different effects of the following two statements:

C1.Cursor = Cursors.WaitCursor

C1.Cursor.Current = Cursors.WaitCursor

I believe the first replaces the entire C1.Cursor object with a new one
while the second only replaces the Current object of C1.Cursor, but I
can't figure when to use which.

Thanks for any help!



Nov 4 '06 #3
Hi,
If you're in some method that will take a while do you set Cursor or
Current?
Setting Cursor.Current doesn't seem to do anything so I wouldn't recommend
using it at all.

If you're going to be processing some long-running task then you should be
doing that on a thread other than the UI thread (see BackgroundWorker class).

If you want to display a WaitCursor for every Form in your application then
set Application.UseWaitCursor = true, or you can set UseWaitCursor on any
particular Control, including Forms.

In many cases you must also disable parts of the UI in code as well as setting
the WaitCursor. e.g., Control.Enabled = false and Form.Enabled = false.
Just before you leave the method do you reset to Default or is that
automatic?
In the "RunWorkerCompleted" event handler for the BackgroundWorker class you
should reset the cursor to Cursors.Default or just set UseWaitCursor = false
(the simpler of the two choices but it only works when you originally set
UseWaitCursor = true).

--
Dave Sexton

" Academic" <ac************@a-znet.comwrote in message
news:ug**************@TK2MSFTNGP03.phx.gbl...
>
If you're in some method that will take a while do you set Cursor or
Current?
Just before you leave the method do you reset to Default or is that
automatic?
Thanks for the help
"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:OY**************@TK2MSFTNGP04.phx.gbl...
>Hi,

If C1 is an instance of a Control:
>>C1.Cursor = Cursors.WaitCursor

This will set the cursor to be the Window's WaitCursor (usually an hour
glass) when the mouse is within the boundaries of the Control and any of
its children
>>C1.Cursor.Current = Cursors.WaitCursor

This will not compile in C#. Cursor.Current is a static property and
cannot


bad example. should be

System.Windows.Forms.Cursor.Current

>be accessed through an instance of a Cursor object. When set, the current
cursor being displayed is supposedly changed, according to the MSDN docs,
but it seems to be reverted back to Cursors.Default immediately in my
testing.


Before leaving the routine the setting is in?

>>
--
Dave Sexton

" Academic" <ac************@a-znet.comwrote in message
news:ub**************@TK2MSFTNGP04.phx.gbl...
>>What are the different effects of the following two statements:

C1.Cursor = Cursors.WaitCursor

C1.Cursor.Current = Cursors.WaitCursor

I believe the first replaces the entire C1.Cursor object with a new one
while the second only replaces the Current object of C1.Cursor, but I
can't figure when to use which.

Thanks for any help!




Nov 4 '06 #4

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:us**************@TK2MSFTNGP03.phx.gbl...
Hi,
>If you're in some method that will take a while do you set Cursor or
Current?

Setting Cursor.Current doesn't seem to do anything so I wouldn't recommend
using it at all.

If you're going to be processing some long-running task then you should be
doing that on a thread other than the UI thread (see BackgroundWorker
class).

If you want to display a WaitCursor for every Form in your application
then set Application.UseWaitCursor = true, or you can set UseWaitCursor on
any particular Control, including Forms.

I had just found the Application.UseWaitCursor in Help.
It said what happens when you set it to true (all open form get set to true)
but not what happens when you set it to false.

I'm thinking about nested routines all setting it to true. Then the
innermost routine sets it to false.
Since it is boolean I'd guess the cursor gets reset on all open forms even
tho some routines are not finished.
and that this is something one must make sure does not happen.
Correct?

Actually as I think about it one has the same problem setting Forms.Cursor.
Correct?
>
In many cases you must also disable parts of the UI in code as well as
setting the WaitCursor. e.g., Control.Enabled = false and Form.Enabled =
false.
>Just before you leave the method do you reset to Default or is that
automatic?

In the "RunWorkerCompleted" event handler for the BackgroundWorker class
you should reset the cursor to Cursors.Default or just set UseWaitCursor =
false (the simpler of the two choices but it only works when you
originally set UseWaitCursor = true).

--
Dave Sexton

" Academic" <ac************@a-znet.comwrote in message
news:ug**************@TK2MSFTNGP03.phx.gbl...
>>
If you're in some method that will take a while do you set Cursor or
Current?
Just before you leave the method do you reset to Default or is that
automatic?
Thanks for the help
"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:OY**************@TK2MSFTNGP04.phx.gbl...
>>Hi,

If C1 is an instance of a Control:

C1.Cursor = Cursors.WaitCursor

This will set the cursor to be the Window's WaitCursor (usually an hour
glass) when the mouse is within the boundaries of the Control and any of
its children

C1.Cursor.Current = Cursors.WaitCursor

This will not compile in C#. Cursor.Current is a static property and
cannot


bad example. should be

System.Windows.Forms.Cursor.Current

>>be accessed through an instance of a Cursor object. When set, the
current cursor being displayed is supposedly changed, according to the
MSDN docs, but it seems to be reverted back to Cursors.Default
immediately in my testing.


Before leaving the routine the setting is in?

>>>
--
Dave Sexton

" Academic" <ac************@a-znet.comwrote in message
news:ub**************@TK2MSFTNGP04.phx.gbl...
What are the different effects of the following two statements:

C1.Cursor = Cursors.WaitCursor

C1.Cursor.Current = Cursors.WaitCursor

I believe the first replaces the entire C1.Cursor object with a new one
while the second only replaces the Current object of C1.Cursor, but I
can't figure when to use which.

Thanks for any help!




Nov 4 '06 #5
Hi,

<snip>
I'm thinking about nested routines all setting it to true. Then the
innermost routine sets it to false.
I prefer that the UI thread handles the cursor logic and the "routines" just
process the business logic. Therefore, it's more common that the "outer"
routine sets the UseWaitCursor property to true before any of the asynchronous
processes are started and false after the entire operation is completed,
including all sub-routines that are being processed asynchronously. This, of
course, only applies to cases where you really can't allow the user to
interact with the all or part of the UI while the processing is taking place.
In some cases unrestricted user-interaction isn't a problem.
Since it is boolean I'd guess the cursor gets reset on all open forms even
tho some routines are not finished.
When UseWaitCursor is set to true before all of the operations are complete,
yes. Try it yourself to verify.
and that this is something one must make sure does not happen.
Correct?
If you allow sub-rountines to control the cursor logic then yes, you may run
into problems when one process sets UseWaitCursor to false while another
asynchronous process hasn't completed yet. You can prevent this by processing
all UI-related logic on the UI thread only, as I suggested above.
Actually as I think about it one has the same problem setting Forms.Cursor.
Correct?
Yes.

--
Dave Sexton

Nov 4 '06 #6
Hi,

Correction:

When UseWaitCursor is set to FALSE before all of the operations are complete,
yes. Try it yourself to verify.

--
Dave Sexton

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:uW**************@TK2MSFTNGP03.phx.gbl...
Hi,

<snip>
>I'm thinking about nested routines all setting it to true. Then the
innermost routine sets it to false.

I prefer that the UI thread handles the cursor logic and the "routines" just
process the business logic. Therefore, it's more common that the "outer"
routine sets the UseWaitCursor property to true before any of the
asynchronous processes are started and false after the entire operation is
completed, including all sub-routines that are being processed
asynchronously. This, of course, only applies to cases where you really
can't allow the user to interact with the all or part of the UI while the
processing is taking place. In some cases unrestricted user-interaction
isn't a problem.
>Since it is boolean I'd guess the cursor gets reset on all open forms even
tho some routines are not finished.

When UseWaitCursor is set to true before all of the operations are complete,
yes. Try it yourself to verify.
>and that this is something one must make sure does not happen.
Correct?

If you allow sub-rountines to control the cursor logic then yes, you may run
into problems when one process sets UseWaitCursor to false while another
asynchronous process hasn't completed yet. You can prevent this by
processing all UI-related logic on the UI thread only, as I suggested above.
>Actually as I think about it one has the same problem setting Forms.Cursor.
Correct?

Yes.

--
Dave Sexton

Nov 4 '06 #7
Thanks for taking so much time to explain.

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:u%****************@TK2MSFTNGP02.phx.gbl...
Hi,

Correction:

When UseWaitCursor is set to FALSE before all of the operations are
complete, yes. Try it yourself to verify.

--
Dave Sexton

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:uW**************@TK2MSFTNGP03.phx.gbl...
>Hi,

<snip>
>>I'm thinking about nested routines all setting it to true. Then the
innermost routine sets it to false.

I prefer that the UI thread handles the cursor logic and the "routines"
just process the business logic. Therefore, it's more common that the
"outer" routine sets the UseWaitCursor property to true before any of the
asynchronous processes are started and false after the entire operation
is completed, including all sub-routines that are being processed
asynchronously. This, of course, only applies to cases where you really
can't allow the user to interact with the all or part of the UI while the
processing is taking place. In some cases unrestricted user-interaction
isn't a problem.
>>Since it is boolean I'd guess the cursor gets reset on all open forms
even tho some routines are not finished.

When UseWaitCursor is set to true before all of the operations are
complete, yes. Try it yourself to verify.
>>and that this is something one must make sure does not happen.
Correct?

If you allow sub-rountines to control the cursor logic then yes, you may
run into problems when one process sets UseWaitCursor to false while
another asynchronous process hasn't completed yet. You can prevent this
by processing all UI-related logic on the UI thread only, as I suggested
above.
>>Actually as I think about it one has the same problem setting
Forms.Cursor.
Correct?

Yes.

--
Dave Sexton


Nov 4 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by SamSpade | last post: by
1 post views Thread by nicholas | last post: by
4 posts views Thread by David Veeneman | last post: by
reply views Thread by jc | last post: by
reply views Thread by leo001 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.