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

  • Thread starter Thread starter Wayne Bradney
  • Start date Start date
W

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,

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
 
Wayne,
I have to wonder if something is calling it indirectly...

Are you showing a dialog box or any UI?

Hope this helps
Jay

Wayne Bradney said:
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
Click to expand...
Click to expand...
 
Nope, no UI at all. It's an interop call to a COM component wrapped using TLBIMP.

Jay B. Harlow said:
Wayne,
I have to wonder if something is calling it indirectly...

Are you showing a dialog box or any UI?

Hope this helps
Jay

Wayne Bradney said:
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.
Click to expand...
Click to expand...
Click to expand...
 
Back
Top