Does DoEvents only affect the current thread?

Question

I have a simple "working" form that works in its thread to inform the user that the application has not died during long operations. To get the working form for the update, I had to insert a call to DoEvents() .

I am curious if this will be just pump messages for the current thread I'm working on, or will it do this for the entire application? I would prefer the main window to remain immune until the operation is completed, so I'm curious how this happens. Below is the code for the work form.

Just to be clear, I'm fine with the code I have, but I would like to know how DoEvents() behaves with threads.

  Public Class frmWorking ''' <summary> ''' Creates and starts a new thread to handle the Working Dialog ''' </summary> ''' <returns>The thread of the Working dialog.</returns> ''' <remarks></remarks> Public Shared Function StartWait() As WorkingFromToken Dim th As New Threading.Thread(AddressOf ShowWait) Dim token As New WorkingFromToken th.Start(token) Return token End Function Private Shared Sub ShowWait(token As WorkingFromToken) Dim frm As New frmWorking Try frm.Show() Do If frm.txtWait.Text.Length > 45 Then frm.txtWait.Text = "Working" Else frm.txtWait.Text &= "." End If Windows.Forms.Application.DoEvents() Threading.Thread.Sleep(250) Loop While token.Running frm.Hide() Catch ex As Threading.ThreadAbortException Threading.Thread.ResetAbort() frm.Hide() Return End Try End Sub End Class 

Answer 1

DoEvents will only pump the current UI thread.

However, I do not recommend your approach.

Instead, you should do your work in the background thread and show the modal execution form in the user interface thread and update it using BeginInvoke or BackgroundWorker .

Answer 2

DoEvents will only affect the thread from which it is called. This will deactivate all Windows messages sent to this stream and send them accordingly. After all messages have been sent, he will return to the caller.

I have a few more comments about your code.

• You basically created your own garbled version of the message loop, repeatedly calling DoEvents in the loop. It would be better to just call Application.Run to initiate a full message loop.
• Creating a message loop in a thread other than the main user interface thread is rarely a good idea. There are some strange things that happen that are hard to handle. For example, a modal dialog box from one thread may overlap a modal dialog from another.
• Trying to catch a ThreadAbortException pointless in most situations. If you ever get this exception, it is possible (perhaps even likely) that the state of the entire AppDomain has been corrupted. Better tear down the application domain than try to gracefully deal with it. This is due to the fact that an exception can be introduced at any time during the execution of the flow, and injection points can be in the middle or in a record, a long operation, or otherwise at some unsafe point.
• As a consequence of the foregoing, do not use Thread.Abort to terminate another thread. There are too many things that can go wrong. It is better to make the thread finish gracefully using safer mechanisms .