MFC UI Thread vs. Background Thread
-
What is the MFC mechanism for accessing UI controls from background threads? In C#, we use "
InvokeRequired
" and "BeginInvoke
" to schedule a function call on the UI thread, but how is that done in MFC?The difficult we do right away... ...the impossible takes slightly longer.
-
What is the MFC mechanism for accessing UI controls from background threads? In C#, we use "
InvokeRequired
" and "BeginInvoke
" to schedule a function call on the UI thread, but how is that done in MFC?The difficult we do right away... ...the impossible takes slightly longer.
In MFC, you should not directly access UI elements from background threads. Instead, you must send messages to the UI thread to get and set elements for the UI. Use can use
SendMessage
orPostMessage
.«_Superman_» _I love work. It gives me something to do between weekends.
-
In MFC, you should not directly access UI elements from background threads. Instead, you must send messages to the UI thread to get and set elements for the UI. Use can use
SendMessage
orPostMessage
.«_Superman_» _I love work. It gives me something to do between weekends.
«_Superman_» wrote:
In MFC, you should not directly access UI elements from background threads.
True.
«_Superman_» wrote:
Instead, you must send messages to the UI thread to get and set elements for the UI.
Use can useSendMessage
orPostMessage
.Not entirely true. The reason for not accessing UI elements from another thread than the main thread is that you can quite easily create a deadlock situation. MFC classes for UI elements uses
::SendMessage()
which will block until the message has been handled. If the main thread is not processing messages, possibly waiting for the thread that manipulates the UI element, the application will deadlock. This of course means that you cannot use::SendMessage()
, even if you call it directly, as it would create the same potential deadlock situation.::PostMessage()
must be used since it doesn't wait for the message to be handled. It is possible to use::SendMessageTimeout()
to avoid a deadlock situation, but if the call fails the receiving thread never gets the message."It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
«_Superman_» wrote:
In MFC, you should not directly access UI elements from background threads.
True.
«_Superman_» wrote:
Instead, you must send messages to the UI thread to get and set elements for the UI.
Use can useSendMessage
orPostMessage
.Not entirely true. The reason for not accessing UI elements from another thread than the main thread is that you can quite easily create a deadlock situation. MFC classes for UI elements uses
::SendMessage()
which will block until the message has been handled. If the main thread is not processing messages, possibly waiting for the thread that manipulates the UI element, the application will deadlock. This of course means that you cannot use::SendMessage()
, even if you call it directly, as it would create the same potential deadlock situation.::PostMessage()
must be used since it doesn't wait for the message to be handled. It is possible to use::SendMessageTimeout()
to avoid a deadlock situation, but if the call fails the receiving thread never gets the message."It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownThanks for clarifying that!
The difficult we do right away... ...the impossible takes slightly longer.
-
What is the MFC mechanism for accessing UI controls from background threads? In C#, we use "
InvokeRequired
" and "BeginInvoke
" to schedule a function call on the UI thread, but how is that done in MFC?The difficult we do right away... ...the impossible takes slightly longer.
SendMessage
andPostMessage
will do the job. You may also like to usePostThreadMessage
instead ofPostMessage
;) -
What is the MFC mechanism for accessing UI controls from background threads? In C#, we use "
InvokeRequired
" and "BeginInvoke
" to schedule a function call on the UI thread, but how is that done in MFC?The difficult we do right away... ...the impossible takes slightly longer.