MFC main UI thread workings and modal dialogs

Question

First let me say that I have roughly searched stackoverflow for this, but couldn't find a specific answer.

My question is rather theoretical and there is no problem with the running of any code. Please consider a simple MFC application with a timer event and a button (attached to an OnClick event).

void SampleDlg::OnTimer(UINT_PTR nIDEvent)
{
    CString msg;
    msg.Format("time: %lld, tid: %d", (int64_t)time(0), GetCurrentThreadId());

    SetWindowText(msg);
}

My intuition suggests that if I sleep inside the OnClick event, main UI thread should hang and timer events shouldn't kick in.

void SampleDlg::OnClick()
{
    Sleep(10000);
}

That is fine, however if I show a new modal dialog inside the OnClick, the timer events still happen. What is different here?

void SampleDlg::OnClick()
{
    CString msg;
    msg.Format("tid: %d is waiting...", GetCurrentThreadId());

    ::MessageBox(GetSafeHwnd(), msg, "Msg", 0);
    // at this point msgbox tells us that thread with tid is waiting

    // thread with tid wont reach this line until msgbox is closed
}

Edit: I have included GetCurrentThreadId() calls to make what i want to ask more clear.

When I run the code above, both msgbox and the window title gives me the same thread-id: 22012 (for example). My question is, what is the value of PC/IP (program counter or instruction pointer) of thread 22012 when msgbox is being shown?

possible duplicate of [If MessageBox()/related are synchronous, why doesn't my message loop freeze?](http://stackoverflow.com/questions/1256963/if-messagebox-related-are-synchronous-why-doesnt-my-message-loop-freeze) — Roger Rowland, Aug 10 '15 at 04:26
@RogerRowland thanks for the link, yes it is the question, but I couldnt find it using the search. Maybe I didnt know how others would word the problem :/ — Sept, Aug 10 '15 at 08:13

xMRi · Accepted Answer · 2015-09-29T07:55:30.250

0

The MessageBox has it's own message loop, like all modal dialogs.

So it uses PeekMessage/GetMessage. WM_TIMER and WM_PAINT messages are pseudo messages that are generated when the message loop executes.

This means that MessageBox internally calls GetMessage or PeekMessage and this causes the effect that the thread still executes MessageBox, but new messages are delivered to you windows.

edited Sep 29 '15 at 07:55

answered Aug 10 '15 at 06:39

xMRi

14,982
3
26
59

Yes, I know other modal dialogs have their own message loop. And even if they have their own UI threads (or not), OnClick() is still blocked, right? How come it doesn't block the main dialog's UI? – Sept Aug 10 '15 at 08:11
No. They don't have their own UI threads. And your main thread isn't blocked. As long as timer messages and other messages arrive nothing is blocked. Even you oNclick code may be executed again, if some windows message arrive that call it. – xMRi Aug 10 '15 at 08:19
Excuse me, but can you elaborate a little? You said "they don't have their own UI threads" and "your main thread isn't blocked". How is it not blocked if it is waiting inside a function? and How other controls are not blocked if they also use they same UI thread? – Sept Sep 15 '15 at 04:17
You thread is always blocked when you wait. You Need always a second thread to do something, when one thread s blocked. A thread can do a Job or it can wait... Y If you open a message box or a new modal Dialog, than the message loop will pump Messages also for your controls. If you want non blocking. Use a separate worker thread and let the main thread still do ist Job pumping Messages. – xMRi Sep 18 '15 at 15:09
I am sorry but you literally not answered anything in my comment. I am still confused. How can "main thread is not blocked" and "they don't have their own UI threads" happen at the same time? You wrote these, right? I am waiting in the main thread, so it is blocked, if other dialogs don't have their own threads, they should be blocked as well. – Sept Sep 28 '15 at 08:44
The main thread isn't blocked because the you execute a code that launches a modal dialog. And this dialog runs its own message loop. So it pumps messages from the queue and this is the reason why you receive timer and paint messages. I already wrote this. – xMRi Sep 28 '15 at 09:00
I think we don't understand each other much, you are not responding what I am asking. I have edited my original question. I hope it is more clear now. – Sept Sep 29 '15 at 07:48
Again. Inside MessageBox there is a call to GetMessage! And a call to GetMessage causes WM_TIMER and WM_PAINT messages to be executed. The difference is simply that Sleep doesn't use GetMessage. So neither timer nor paint messages are generated. Adding thread ids just still show you, that you are in the same thread... ;)´ Also I changed my answer. – xMRi Sep 29 '15 at 07:52

MFC main UI thread workings and modal dialogs

1 Answers1