C / C++ / MFC

Re: PeekMessage and DoEvents [modified]

Rajesh R Subramanian18-Jan-10 8:49

Rajesh R Subramanian

18-Jan-10 8:49

I just looked what the DoEvents call does and it looks functionally similar to the loop you've written. But it's just that in this case you're translating and dispatching the messages yourselves, but in the VB case you'll be transferring control to the OS and it does the thing for you.

If you're going to use such a loop in your code, you may want to consider using a worker thread instead (but that really depends on what exactly are you trying to achieve).

“Follow your bliss.” – Joseph Campbell

Rozis18-Jan-10 11:49

Rozis

18-Jan-10 11:49

Rajesh R Subramanian wrote:
I just looked what the DoEvents call does and it looks functionally similar to the loop you've written. But it's just that in this case you're translating and dispatching the messages yourselves, but in the VB case you'll be transferring control to the OS and it does the thing for you.

This is not true: even in VB, the VB-runtime does the thing for you and not the OS.

What happens is that the message-queue is dispatched till it is empty. From that point Windows can give its time to others. 'Transferring control to the OS" then means giving the time you don't need because the queue is empty, back to the OS.

Rajesh R Subramanian wrote:
If you're going to use such a loop in your code, you may want to consider using a worker thread instead (but that really depends on what exactly are you trying to achieve).

Actually that would make things worse: every thread has its own message-queue.

Rozis

modified on Monday, January 18, 2010 5:56 PM

Rajesh R Subramanian18-Jan-10 19:15

Rajesh R Subramanian

18-Jan-10 19:15

Rozis wrote:
This is not true: even in VB, the VB-runtime does the thing for you and not the OS.

While I know nothing about VB, this is from the docs of the said function: DoEvents passes control to the operating system. Control is returned after the operating system has finished processing the events in its queue and all keys in the SendKeys queue have been sent. So, the documentation could be wrong.

Rozis wrote:
Actually that would make things worse: every thread has its own message-queue.

What an ignorant statement! Every thread won't have its own message queue. A thread will have a message queue only if it's an UI thread!

“Follow your bliss.” – Joseph Campbell

Rozis19-Jan-10 2:17

Rozis

19-Jan-10 2:17

<blockquote class="FQ"><div class="FQA">Rajesh R Subramanian wrote:</div>While I know nothing about VB, this is from the docs of the said function: DoEvents passes control to the operating system. Control is returned after the operating system has finished processing the events in its queue and all keys in the SendKeys queue have been sent. So, the documentation could be wrong.</blockquote>

The documentation is not wrong. It states exactly - in other words - my point.

<blockquote class="FQ"><div class="FQA">Rajesh R Subramanian wrote:</div>What an ignorant statement! Every thread won't have its own message queue. A thread will have a message queue only if it's an UI thread! </blockquote>

I'm sorry: of course you are right. But the problem was: is it a good idea to move the dispatcher to another thread. I think not because 1) there's not performance gain, 2) it complicates the dispatcher, and 3) if he makes a mistake it's reading the wrong message-queue.

The initial question was: is the dispatcher written equivalent to the VB DoEvents. In my opinion it is an exact copy. I believe in this situation introducing an extra thread has no meaning, but i'll be pleased to be convinced by you. The statement was not a lack of knowledge from my side but I thought your answer got of the track of the initial question. I'm really sorry if i offended you: that was not my intention.

As Pallini pointed out: although threads will not initially have a message-queue, they will if you use any of the message-functions. So my question to you is how would you create a thread with a dispatcher that dispatches the message-queue of another thread? I simply don't get it. If you move the code of the dispatcher to another thread it will dipatch the thread's queue and not the queue of your main program.

Rozis

CPallini18-Jan-10 20:58

18-Jan-10 20:58

Rozis wrote:
every thread has its own message-queue.

True: though on 16-bit Windows [^]... Roll eyes | :rolleyes:

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke

[My articles]

win32 dialog

john563218-Jan-10 1:58

john5632

18-Jan-10 1:58

Hi,

I tried with win32 dialog..woking fine with button and list control but when I place a tab control or tree control...dialog does not appear but runs behind.

What might be the problem?

Re: win32 dialog

Abhi Lahare18-Jan-10 6:16

Abhi Lahare

18-Jan-10 6:16

adjust the positions of all child control properly

Threading

HakunaMatada18-Jan-10 1:48

HakunaMatada

18-Jan-10 1:48

Could someone direct me to a resource on threading for C++? I am familiar with threading but I would like to learn more about thread synchronization, UI Threads, Updating UI via worker threads, etc. Also, I would also like to learn about memory profiling and finding memory leaks in the code. Any kind of help would be deeply appreciated.

Also, is it ok to update the UI of a dialog from a worker thread using SendMessage/PostMessage? How do I handle multiple worker threads making changes to the same UI?

Thank You.

---

Hakuna-Matata Beer | [beer]

It means no worries for the rest of your days...
It's our problem free, Philosophy
Jig | [Dance]

"I think my response was 'What idiot dreamed this up?'" -- Mary Ann Davidson, Oracle's chief security officer, in typical blunt manner, remembering her reaction to the company's scheme to brand its databases as "unbreakable."

Cedric Moonen18-Jan-10 2:08

Cedric Moonen

18-Jan-10 2:08

Here[^] is one of the best article I've read about threading. It will answer a lot of your questions.

Cédric Moonen
Software developer

Charting control [v3.0 - Updated]
OpenGL game tutorial in C++

HakunaMatada18-Jan-10 2:11

HakunaMatada

18-Jan-10 2:11

Thank You Cedric. Your help is much appreciated. Smile | :)

---

Hakuna-Matata Beer | [beer]

It means no worries for the rest of your days...
It's our problem free, Philosophy
Jig | [Dance]

Moak18-Jan-10 3:34

Moak

18-Jan-10 3:34

Hi, here is more stuff to read:

- Using Worker Threads[^] by Joseph M. Newcomer
- Threads, Processes and IPC[^] on CodeProject

Enjoy Smile | :)

Webchat in Europe Java | [Coffee]

(only 4K)

HakunaMatada19-Jan-10 1:26

HakunaMatada

19-Jan-10 1:26

Thank You! Smile | :)

---

Hakuna-Matata Beer | [beer]

It means no worries for the rest of your days...
It's our problem free, Philosophy
Jig | [Dance]

Close A DIalog

john563218-Jan-10 0:58

john5632

18-Jan-10 0:58

Hi,

I tried to create a dialog (Modal) based application using win32. It is working but
at close button not able to close.

It is disappearing but not closing properly..my mean to say is that running behind..I checked with Task Manager.

Code for CallBack procedure is as:

BOOL CALLBACK ToolDlgProc(HWND hwnd, UINT Message, WPARAM wParam, LPARAM lParam)

case WM_COMMAND:
switch(LOWORD(wParam))
{
case IDOK:
EndDialog(hwnd, wParam);
return (INT_PTR)TRUE;
}
break;

What is the wrong?

Re: Close A DIalog

Code-o-mat18-Jan-10 1:25

Code-o-mat

18-Jan-10 1:25

My guess is that your main message loop keeps on going. Just because you close a dialog the program's message loop won't quit. Depending on your implementation you need to somehow tell the loop to stop processing messages, for example by using PostQuitMessage[^].

> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Sometimes you just have to hate coding to do it well. <

Re: Close A DIalog

john563218-Jan-10 1:29

john5632

18-Jan-10 1:29

Thank you

Thread paused

susanne117-Jan-10 23:56

susanne1

17-Jan-10 23:56

I have a thread, it is has a normal priority, when it starts to excute, it runs for 5 or 6 seconds then stops for 3 or 4 seconds and run again, stops again this goes till it finishes his work. Any idea why this happens, programm code is in Visual C++.
Thanks

CPallini18-Jan-10 0:16

18-Jan-10 0:16

Isn't that (being scheduled) the normal thread beahviour?
Smile | :)

susanne118-Jan-10 0:50

susanne1

18-Jan-10 0:50

i changed the thread priority to HIGHEST, but it didi not help.

CPallini18-Jan-10 0:58

18-Jan-10 0:58

Simply don't do that. It is normal for threads being scheduled.
Smile | :)

Covean18-Jan-10 0:59

Covean

18-Jan-10 0:59

Being scheduled is normal thread behaviour! But it's not a normal thread behaviour to wait 3-5 seconds to get the next time slice!

Greetings
Covean

CPallini18-Jan-10 1:39

18-Jan-10 1:39

True but it really depends on how those 3-5 seconds come out? Are they just a OP impression? How did she measure them?
Smile | :)

Covean18-Jan-10 1:57

Covean

18-Jan-10 1:57

Yes there you are right. But in normal nobody should notice the thread-switches (if the thread and the process doesn't have the lowest priority or many real-time priority processes are running), so I would assume that the op has a real problem with it, no matter if the thread pauses for 300-500ms or 3-5s.

Greetings
Covean

xushih19-Jan-10 1:38

xushih

19-Jan-10 1:38

use function Sleep(n_time).

CPallini19-Jan-10 1:54