UI Responsiveness and DoEvents

[Guest]

This is a 6.0 v. .NET question. In 6.0, you worked around the fact that
everything ran on the UI thread by judiciously invoking DoEvents to keep the
message queue clear. Using this approach I was able to write UIs that were
very responsive. Ironically, .NET has made this a lot harder to do by forcing
the programmer to solve the same problem with multi-threading. Granted that
makes the hard things possible, but the easy things hard. I'm using a
variation of BackgroundWorker to deal with my non-UI processing, but there is
still a problem that this doesn't solve. Suppose you have a form that has to
do some time-consuming processing before it can display itself, processing
that can't be separated out into another thread. In .NET there doesn't appear
to be any way to display some kind of busy state (e.g., hourglass cursor).
Because the form executes on the UI thread, the call to change the cursor
shape is not displayed in the UI until after the form completes its
processing. In 6.0, this is easily solved by calling DoEvents after the
cursor-change but before the Form is called. DoEvents still exists in .NET,
but doesn't seem to actually do anything. At any rate, this technique doesn't
work anymore. This seems like a pretty common basic scenario. How is it done?
Thanks.

 

[Guest]

If I do this
Me.Cursor = Cursors.WaitCursor
Sleep(2000)
Me.Cursor = Cursors.Arrow
in a form (Me refers to the form), I see an hour glass for 2 seconds. You
don't need doevents to change the cursor. There may be an issue regarding
different controls each with their own cursor property, but that is separate
from the doevents question.

 

[Linda Liu [MSFT]]

Hi,

Thank you for posting.

Application.DoEvents method processes all Windows messages currently in the
message queue.

When you run a Windows Form, it creates the new form, which then waits for
events to handle. Each time the form handles an event, it processes all the
code associated with that event. All other events wait in the queue. While
your code handles the event, your application does not respond. For
example, the window does not repaint if another window is dragged on top.

If you call DoEvents in your code, your application can handle the other
events. For example, if you have a form that adds data to a ListBox and add
DoEvents to your code, your form repaints when another window is dragged
over it. If you remove DoEvents from your code, your form will not repaint
until the click event handler of the button is finished executing.
Typically, you use this method in a loop to process messages.

The conception of the DoEvents in .NET is almost the same as in VS6.0.

The cursor is specific to a control in .NET. You could specify the cursor
for a form and another cursor for a button. Before a form completes
loading, there is no effect by specifying the cursor for it. This issue is
not related to the DoEvents method.

If you want to display hourglass cursor while the form is doing some
time-consuming processing, I recommend you to use the BackgroundWorker to
do this work and disable the UI elements on the form. After you call the
RunWorkerAsync method of the BackgroundWorker, you may set the form's
cursor to WaitCursor by the statement "this.Cursor = Cursors.WaitCursor".
And in the BackgroundWorker's RunWorkerCompleted event handler, you may
restore the form's cursor and enable the UI elements on the form.

Hope this helps.
If you have anything unclear, please don't hesitate to let me know.



Sincerely,
Linda Liu
Microsoft Online Community Support

====================================================
When responding to posts,please "Reply to Group" via
your newsreader so that others may learn and benefit
from your issue.
====================================================