60

Is there a difference between Cursor.Current and this.Cursor (where this is a WinForm) in .Net? I've always used this.Cursor and have had very good luck with it but I've recently started using CodeRush and just embedded some code in a "Wait Cursor" block and CodeRush used the Cursor.Current property. I've seen on the Internet and at work where other programmers have had some problems with the Cursor.Current property. It just got me to wondering if there is a difference in the two. Thanks in advance.

I did a little test. I have two winforms. I click a button on form1, set the Cursor.Current property to Cursors.WaitCursor and then show form2. The cursor doesn't change on either form. It remains Cursors.Default (pointer) cursor.

If I set this.Cursor to Cursors.WaitCursor in the button click event on form1 and show form2, the wait cursor only shows on form1 and the default cursor is on form2 which is expected. So, I still don't know what Cursor.Current does.

General Grievance
  • 4,555
  • 31
  • 31
  • 45
Keith
  • 922
  • 2
  • 10
  • 12

8 Answers8

91

Windows sends the window that contains the mouse cursor the WM_SETCURSOR message, giving it an opportunity to change the cursor shape. A control like TextBox takes advantage of that, changing the cursor into a I-bar. The Control.Cursor property determines what shape will be used.

The Cursor.Current property changes the shape directly, without waiting for a WM_SETCURSOR response. In most cases, that shape is unlikely to survive for long. As soon as the user moves the mouse, WM_SETCURSOR changes it back to Control.Cursor.

The UseWaitCursor property was added in .NET 2.0 to make it easier to display an hourglass. Unfortunately, it doesn't work very well. It requires a WM_SETCURSOR message to change the shape and that won't happen when you set the property to true and then do something that takes a while. Try this code for example:

private void button1_Click(object sender, EventArgs e) {
  this.UseWaitCursor = true;
  System.Threading.Thread.Sleep(3000);
  this.UseWaitCursor = false;
}

The cursor never changes. To whack that into shape, you'll need to use Cursor.Current as well. Here is a little helper class to make it easy:

using System;
using System.Windows.Forms;

public class HourGlass : IDisposable {
  public HourGlass() {
    Enabled = true;
  }
  public void Dispose() {
    Enabled = false;
  }
  public static bool Enabled {
    get { return Application.UseWaitCursor; }
    set {
      if (value == Application.UseWaitCursor) return;
      Application.UseWaitCursor = value;
      Form f = Form.ActiveForm;
      if (f != null && f.Handle != IntPtr.Zero)   // Send WM_SETCURSOR
        SendMessage(f.Handle, 0x20, f.Handle, (IntPtr)1);
    }
  }
  [System.Runtime.InteropServices.DllImport("user32.dll")]
  private static extern IntPtr SendMessage(IntPtr hWnd, int msg, IntPtr wp, IntPtr lp);
}

And use it like this:

private void button1_Click(object sender, EventArgs e) {
  using (new HourGlass()) {
    System.Threading.Thread.Sleep(3000);
  }
}
Blorgbeard
  • 101,031
  • 48
  • 228
  • 272
Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • 1
    I ran into a case when combining this with a splash screen that would cause an InvalidOperationException - "Cross-thread operation not valid". Adding a !f.InvokeRequired between f!=null and f.Handle!=null resolved the issue. – Daniel Ballinger Feb 14 '11 at 02:17
  • This works great for me, but according to ReSharper, "Expression is always true" on this line: if (f != null && f.Handle != null) // Send WM_SETCURSOR – B. Clay Shannon-B. Crow Raven Jul 03 '12 at 17:37
  • This is an AWESOME helper class. Worked when nothing else did. – KeithS Aug 25 '12 at 01:44
  • When setting UseWaitCursor to false, the cursor is not updated until the user moves the mouse. You should add the following code to the end: Cursor.Position = Cursor.Position; // Refresh cursor – arni Nov 17 '13 at 22:56
  • 1
    If you can't get the cursor to update *after* the slow code finished running then you're doing it wrong. – Hans Passant Nov 17 '13 at 22:57
  • `using` is a cool idea for simple operations. I ended up implementing a stack to solve the problem where Sleep(3000) is instead another function which itself uses an hourglass to prevent the cursor from being changed back too early. – Dan Bechard Nov 05 '14 at 14:33
  • 1
    You might want to change the above code to something like this: ` Form f = Form.ActiveForm; f.Invoke(() => { if (f != null && f.Handle != IntPtr.Zero) { // Send WM_SETCURSOR SendMessage(f.Handle, 0x20, f.Handle, (IntPtr)1); } }); ` This change let's you call HourGlass.Enabled from a background thread (avoiding cross-thread calls and the respective exception). Sascha – Sascha Dec 04 '14 at 07:30
12

I believe that Cursor.Current is the mouse cursor currently being used (regardless of where it is on the screen), while this.Cursor is the cursor it will be set to, when the mouse passes over your window.

James Curran
  • 101,701
  • 37
  • 181
  • 258
  • This seems to be **not true**. I created a sample application to verify this and it seems that `System.Windows.Cursors.Current` is updated only when cursor change is associated with application window. – Lukasz M Jun 24 '12 at 17:17
  • The difference is that `this.Cursor` is not updated even if cursor is over a child control of a window or over window's non-client area. Sorry for two subsequent comments, time allowed for editing the first one has ended. – Lukasz M Jun 24 '12 at 17:29
7

this.Cursor is the cursor that will be used when the mouse is over the window referred to by this. Cursor.Current is the current mouse cursor, which might be different from this.Cursor if the mouse is over a different window.

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
6

Actually if you would like to use HourGlass from another thread that will give you back cross-threading exception because you are trying to access f.Handle from different thread than form was originally created. Use GetForegroundWindow() instead from user32.dll.

[DllImport("user32.dll")]
private static extern IntPtr GetForegroundWindow();

and then

public static bool Enabled
{
    get
    {
        return Application.UseWaitCursor;
    }

    set
    {
        if (value == Application.UseWaitCursor)
        {
            return;
        }

        Application.UseWaitCursor = value;
        var handle = GetForegroundWindow();
        SendMessage(handle, 0x20, handle, (IntPtr)1);
    }
}
4

I have noticed an interesting thing about setting cursors, so I would like to clear some misunderstandings that I myself had before and I hope it may help others too:

When you try to set a form's cursor by using

this.cursor = Cursors.Waitcursor

you actually set the cursor for the control and not the whole form since cursor is property of the Control class.

Also of course the cursor will only be changed to the given cursor when the mouse is actually over the actual control (explicitly the form's area)

As Hans Passant has already stated that:

Windows sends the window that contains the mouse cursor the WM_SETCURSOR message, giving it an opportunity to change the cursor shape

I don't know if windows sends messages directly to controls or if the form relays those messages to it's child controls based on mouse position, I'd most likely guess on the first method since when i fetched the messages with overriding WndProc of the form control, when i was over the textbox for example, the form didn't process any messages. (please someone give clarity on this)

Basically my suggestion would be to reside from using this.cursor also and stick to this.usewaitcursor, since that changes the cursor property to waitcursor for all child controls.

The problem with this is also the same as with the application level Application.usewaitcursor, while you are not over the form/forms with your cursor no WM_SETCURSOR message is being sent by windows, so if you start a time consuming synchronous operation before moving your mouse over the form's area, the form can only process such message when the time consuming synchronous operation finishes.

(I would not suggest running time consuming tasks in the UI thread at all, mainly this is what is causing the issue here)

I made a little improvement on Hans Passant's answer, so the hourglass can be either set on application level or form level, also avoiding InvalidOperationException from cross threaded operation calls:

using System;
using System.Windows.Forms;

public class HourGlass : IDisposable
{
    public static bool ApplicationEnabled
    {
        get{ return Application.UseWaitCursor; }
        set
        {
            Form activeFrom = Form.ActiveForm;
            if (activeFrom == null || ApplicationEnabled == value) return;
            if (ApplicationEnabled == value)return;
            Application.UseWaitCursor = (bool)value;

            if (activeFrom.InvokeRequired)
            {
                activeFrom.BeginInvoke(new Action(() =>
                {
                    if (activeFrom.Handle != IntPtr.Zero)
                    SendMessage(activeFrom.Handle, 0x20, activeFrom.Handle, (IntPtr)1); // Send WM_SETCURSOR
                }));
            }
            else
            {
                if (activeFrom.Handle != IntPtr.Zero)
                SendMessage(activeFrom.Handle, 0x20, activeFrom.Handle, (IntPtr)1); // Send WM_SETCURSOR
            }
        }
    }

    private Form f;

    public HourGlass() 
    {
        this.f = Form.ActiveForm;

        if (f == null)
        {
            throw new ArgumentException();
        }
        Enabled = true;
    }

    public HourGlass(bool enabled)
    {
        this.f = Form.ActiveForm;

        if (f == null)
        {
            throw new ArgumentException();
        }
        Enabled = enabled;
    }

    public HourGlass(Form f, bool enabled)
    {
        this.f = f;

        if (f == null)
        {
            throw new ArgumentException();
        }
        Enabled = enabled;
    }

    public HourGlass(Form f)
    {
        this.f = f;

        if (f == null)
        {
            throw new ArgumentException();
        }

        Enabled = true;
    }

    public void Dispose()
    {
        Enabled = false;
    }

    public bool Enabled
    {
        get { return f.UseWaitCursor; }
        set
        {
            if (f == null || Enabled == value) return;
            if (Application.UseWaitCursor == true && value == false) return;

            f.UseWaitCursor = (bool)value;

            if(f.InvokeRequired)
            {
                f.BeginInvoke(new Action(()=>
                {
                    if (f.Handle != IntPtr.Zero)
                    SendMessage(f.Handle, 0x20, f.Handle, (IntPtr)1); // Send WM_SETCURSOR
                }));
            }
            else
            {
                if (f.Handle != IntPtr.Zero)
                SendMessage(f.Handle, 0x20, f.Handle, (IntPtr)1); // Send WM_SETCURSOR
            }
        }
    }

    [System.Runtime.InteropServices.DllImport("user32.dll")]
    private static extern IntPtr SendMessage(IntPtr hWnd, int msg, IntPtr wp, IntPtr lp);
}

To use it on application level:

try
{
  HourGlass.ApplicationEnabled = true;
  //time consuming synchronous task
}
finally
{
  HourGlass.ApplicationEnabled = false;
}

For using it on form level you can either use for the current active form:

using (new HourGlass())
{
  //time consuming synchronous task
}

or you can initialize a local variable in the form like this:

public readonly HourGlass hourglass;

public Form1()
{
    InitializeComponent();
    hourglass = new HourGlass(this, false);
}

and use it later in a try catch finally block

Attila Horváth
  • 562
  • 1
  • 5
  • 16
0

This works great for me when the LongRunningOperation() is processing messages.

private void btnDoLongRunningOperation_Click(object sender, System.EventArgs e)
{
    this.Cursor = Cursors.WaitCursor;
    LongRunningOperation();
    this.Cursor = Cursors.Arrow;
}
bootsn
  • 1
  • 1
  • 1
    What if the LongRunningOperation fails? Should at least have a try/finally here. Also What if the cursor is not an Arrow to begin with e.g. you are in a TextBox? – Sam Mackrill Mar 24 '15 at 17:34
  • A better way to do this is to create a small class (which implements IDisposable). Set the WaitCursor in the constructor, storing the previous cursor. In the Dispose method, set the cursor back. Then all you need is `using (var cw = new CursorWaiter()){}` – Flydog57 Jul 21 '22 at 19:53
0

From VB.net VS 2012

Windows.Forms.Cursor.Current = Cursors.Default
Elian
  • 60
  • 6
0

The code from Hans Passant is not useful for me because it happens very often that I set the wait cursor in one class and reset it in another class.

For example the user clicks a button "Connect", the wait cursor is shown, in a background thread a connection is established and when it is ready the cursor must be reset to normal.

The Hourglass class from Hans is too unflexible for this scenario. Also a Windows Message is not required to set the cursor.

I use this in a class Utils:

public class Utils
{
    static Form mi_WaitCursorForm;

    // i_Control may be a Control or a Form
    public static void ShowWaitCursor(Control i_Control)
    {
        // Wait cursor may still be set for another Form
        HideWaitCursor();

        Form i_Form = i_Control as Form;
        if (i_Form == null)
        {
            if (i_Control != null)
            {
                i_Form = (Form)i_Control.TopLevelControl;
            }
            else
            {
                Debug.Assert(false, "A control or Form should be specified!");
                i_Form = Form.ActiveForm;
            }
        }

        // i_Form.UseWaitCursor = true does NOT work always
        i_Form.Cursor = Cursors.WaitCursor;
        mi_WaitCursorForm = i_Form;
        Application.DoEvents();
    }

    public static void HideWaitCursor()
    {
        Form i_Form = mi_WaitCursorForm;
        if (i_Form == null)
            return;
            
        i_Form.Cursor = Cursors.Arrow;
        mi_WaitCursorForm = null;
       
        // Fix for bug in .NET framework: sometimes the wait cursor does not disappear.
        Cursor.Position = Cursor.Position;
        Application.DoEvents();
    }
}
Elmue
  • 7,602
  • 3
  • 47
  • 57