Cursor won't stay as I set it (WaitCursor)

[Wayne Bradney]

Hi,
I have an application where the login to the server could take 30-40
seconds. I have a main form with a "Login" button on it and a handler:

private void btnLogin_Click(object sender, System.EventArgs e) {
Cursor.Current = Cursors.WaitCursor;
log.Debug("About to open session");
session = Session.Open("username", "password", "instance", "server");
log.Debug("Opened session");
btnAdapters.Enabled = true;
btnCache.Enabled = true;
Cursor.Current = Cursors.Default;
}

The Session class encapsulates the login/logout operations (which are
interop calls to COM code). What's happening is that the Cursor stays
as an hourglass for about 10 seconds and then changes back to an arrow
- while the login is still executing. Session.Open doesn't return; the
other buttons stay disabled and the form doesn't respond to mouse
clicks immediately, but 20-30 seconds later (when the login operation
completes), the other buttons are enabled and all of the mouse clicks
I performed while the form appeared "dead" suddenly take effect (forms
start popping up).

How do I set the hourglass and kill the mouse for the full duration of
the opration, like I could with VB6? If I replace the login code with
a line that puts the thread to sleep for 40 seconds, I don't see the
same behaviour: the hourglass stays around for the full 40 seconds and
the form is truly dead to mouse operations - which is just what I
want.

 

[Jay B. Harlow [MVP - Outlook]]

Wayne,
Are you calling Application.DoEvents either implicitly or explicitly with
the Session object (or something that it calls)?

The cursor will revert to the cursor for the 'control' rather then the one
you set, if DoEvents is called.

Read the first Note under Remarks at:
http://msdn.microsoft.com/library/d...l/frlrfSystemWindowsFormsCursorClassTopic.asp

Hope this helps
Jay

 

[Wayne Bradney]

Jay,

I was aware of the DoEvents thing and I checked to make sure I wasn't
calling it directly - and I'm not. I did, however, find that I could
get the correct behaviour by using:

this.Cursor = Cursors.WaitCursor

instead of

Cursor.Current = Cursors.WaitCursor

I'm happy to do this, but I'm still not convinced that the .Current
approach isn't somehow broken.

Thanks,
WMB

 

[Jay B. Harlow [MVP - Outlook]]

Wayne,
I have to wonder if something is calling it indirectly...

Are you showing a dialog box or any UI?

Hope this helps
Jay

Jay,

I was aware of the DoEvents thing and I checked to make sure I wasn't
calling it directly - and I'm not. I did, however, find that I could
get the correct behaviour by using:

this.Cursor = Cursors.WaitCursor

instead of

Cursor.Current = Cursors.WaitCursor

I'm happy to do this, but I'm still not convinced that the .Current
approach isn't somehow broken.

Thanks,
WMB

"Jay B. Harlow [MVP - Outlook]" <[email protected]> wrote in message

Wayne,
Are you calling Application.DoEvents either implicitly or explicitly with
the Session object (or something that it calls)?

The cursor will revert to the cursor for the 'control' rather then the one
you set, if DoEvents is called.

Read the first Note under Remarks at:
http://msdn.microsoft.com/library/d...l/frlrfSystemWindowsFormsCursorClassTopic.asp

Hope this helps
Jay

 

[Wayne Bradney]

Nope, no UI at all. It's an interop call to a COM component wrapped using TLBIMP.

Wayne,
I have to wonder if something is calling it indirectly...

Are you showing a dialog box or any UI?

Hope this helps
Jay

Jay,

I was aware of the DoEvents thing and I checked to make sure I wasn't
calling it directly - and I'm not. I did, however, find that I could
get the correct behaviour by using:

this.Cursor = Cursors.WaitCursor

instead of

Cursor.Current = Cursors.WaitCursor

I'm happy to do this, but I'm still not convinced that the .Current
approach isn't somehow broken.

Thanks,
WMB

"Jay B. Harlow [MVP - Outlook]" <[email protected]> wrote in message

Wayne,
Are you calling Application.DoEvents either implicitly or explicitly with
the Session object (or something that it calls)?

The cursor will revert to the cursor for the 'control' rather then the one
you set, if DoEvents is called.

Read the first Note under Remarks at:
http://msdn.microsoft.com/library/d...l/frlrfSystemWindowsFormsCursorClassTopic.asp

Hope this helps
Jay

Hi,
I have an application where the login to the server could take 30-40
seconds. I have a main form with a "Login" button on it and a handler:

private void btnLogin_Click(object sender, System.EventArgs e) {
Cursor.Current = Cursors.WaitCursor;
log.Debug("About to open session");
session = Session.Open("username", "password", "instance", "server");
log.Debug("Opened session");
btnAdapters.Enabled = true;
btnCache.Enabled = true;
Cursor.Current = Cursors.Default;
}

The Session class encapsulates the login/logout operations (which are
interop calls to COM code). What's happening is that the Cursor stays
as an hourglass for about 10 seconds and then changes back to an arrow
- while the login is still executing. Session.Open doesn't return; the
other buttons stay disabled and the form doesn't respond to mouse
clicks immediately, but 20-30 seconds later (when the login operation
completes), the other buttons are enabled and all of the mouse clicks
I performed while the form appeared "dead" suddenly take effect (forms
start popping up).

How do I set the hourglass and kill the mouse for the full duration of
the opration, like I could with VB6? If I replace the login code with
a line that puts the thread to sleep for 40 seconds, I don't see the
same behaviour: the hourglass stays around for the full 40 seconds and
the form is truly dead to mouse operations - which is just what I
want.