wayne
Thu Jan 29 10:36:23 CST 2004
Nope, no UI at all. It's an interop call to a COM component wrapped using TLBIMP.
"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message news:<eLrOQ0S5DHA.1816@TK2MSFTNGP12.phx.gbl>...
> 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" <wayne.bradney@usa.net> wrote in message
> news:6170aeb9.0401270745.3e017bb3@posting.google.com...
> > 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]" <Jay_Harlow_MVP@msn.com> wrote in message
> news:<etJfz5D5DHA.2412@TK2MSFTNGP09.phx.gbl>...
> > > 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/default.asp?url=/library/en-us/cpref/html/frlrfSystemWindowsFormsCursorClassTopic.asp
> > >
> > > Hope this helps
> > > Jay
> > >
> > > "Wayne Bradney" <wayne.bradney@usa.net> wrote in message
> > > news:6170aeb9.0401260956.1063a286@posting.google.com...
> > > > 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.