Re: Reliable way to change the cursor

"Luke R" <dont@xxxxxxx> schrieb
Am i confused or are you saying that you shouldnt use the WaitCursor
if you are using DoEvents?

Yes. DoEvents means that the user can interact with the application, whereas
a WaitCursor indicates that he can not. Therefore I would not show a
WaitCursor if I called Doevents.

It works if the ui thread is locked (i.e. running a process). But
what about if i want to write status messages to the status bar
during the process? The only way to make them display is by calling
DoEvents.


This really pisses me off.

Me too! The reason for this is that since WinXP we don't have the choice
only to OUT-put something without accepting IN-put.

But to start from the beginning: Til Win98 (or ME) you could have a busy
application (without doevents) and still update the display. We had to call
the control's Refresh method after, for example, updating a label's text.
Worked well. The user must not operate the application in this time. At
least this was our (programmer's) choice.

Since WinXP there are ghost windows: (2nd paragraph)
http://msdn2.microsoft.com/en-us/library/ms644927.aspx

This means: If we want to update the display, it is not sufficient to call
the control's Refresh method because our window might have been replaced by
a ghost window. In order to update the display we are forced to keep the
application responsive, but this means the user can also interact with the
application although we don't want this and we only want to update the
display. This can cause a lot of work because the state working+responsive
must be handled. So, we have to use Doevents (which I never use), or put
the work in a separate thread.

One day I found a workaround for this problem without using
Doevents or another thread: In addition to calling the control's Refresh
method, call the PeekMessage API function during your
process. This prevents the window from being replaced by a ghost window.

Now that I've been googling the history of this topic, I came across a
probably helpful new feature:
http://support.microsoft.com/kb/817611

I've no clue yet what it is but I'll have a look at it. Maybe it helps you
too. Seems to be a problem fixed with SP2, but the Toolkit might be interesting....


So, if you don't use Doevents anymore, you can use the Waitcursor. But, if
you want to use Doevents, don't show the Waitcursor.


Armin

Why cant things just work the way they
say they do. Especially with something as fundamental as the wait
cursor.

UseWaitCursor: "Gets or sets a value indicating whether to use the
wait cursor for the current control and all child controls."

That is false. It simply doesnt work like that.


"Armin Zingler" <az.nospam@xxxxxxxxxx> wrote in message
news:edlUhvQuHHA.4952@xxxxxxxxxxxxxxxxxxxxxxx
> "Luke R" <dont@xxxxxxx> schrieb
> > At first i thought that didnt even work at all, and then i
> > discovered that it works if you dont touch the mouse... if you
> > move the mouse one pixel in any direction it goes back to the
> > default
> > cursor for the object the cursor is over.
>
> Works here. I assumed that the WaitCursor only makes sense if the
> thread is
> busy. Then it should work. If it is not busy, or if you use
> Application.Doevents, then it does not work, but then one
> shouldn't use the WaitCursor (IMO).
>
>
> Armin
>
>


.

Relevant Pages

  • Re: Reliable way to change the cursor
    ... Running operations on a background process is not always practical, so when I do need to wait for a web service call to return, I need the cursor to be the wait cursor. ... The only reason I use DoEvents is because I need the status label to update... ... run long enough for a ghost window to be created? ... WaitCursor over all controls on my form until I explicitly set it ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Reliable way to change the cursor
    ... Refresh thing, but that sounded alright. ... run long enough for a ghost window to be created? ... > But, if you want to use DoEvents, don't show the Waitcursor. ... WaitCursor over all controls on my form until I explicitly set it ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Reliable way to change the cursor
    ... Does this mean the .Refresh solution for updating status messages will still work for processes which do not run long enough for a ghost window to be created? ... Why do you never use DoEvents? ... is a reliable way of making sure the cursor remains WaitCursor over all controls on my form until I explicitly set it back to default. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Reliable way to change the cursor
    ... Am i confused or are you saying that you shouldnt use the WaitCursor if you are using DoEvents? ... Especially with something as fundamental as the wait cursor. ... If it is not busy, ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Problem with enabling a button
    ... Private Sub Command1_Click ... That's a standard problem and is easily fixed by using a DoEvents immediately before the Command1.Enabled = True line, thereby causing the second and third "queued clicks" to be actioned just *before* the code sets Command1.Enabled back to True. ... When you run the above code and click the button rapidly three times in succession, and then dismiss the MsgBox in the normal manner when it appears, you will see that the MsgBox *in this specific case* has had an effect similar to DoEvents. ... the fact that your own code is behaving differently depending on whether you display a MsgBox or not is not in itself a cause for concern. ...
    (microsoft.public.vb.general.discussion)