PeekMessage and DoEvents
-
Is the following snippet of MFC code similar to the DoEvents() functionality in Visual Basic?
MSG msg;
if(PeekMessage(&msg, AfxGetMainWnd()->m_hWnd, 0, 0, PM_REMOVE))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}--- :beer: Hakuna-Matata :beer: It means no worries for the rest of your days... It's our problem free, Philosophy :jig: "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."
-
Is the following snippet of MFC code similar to the DoEvents() functionality in Visual Basic?
MSG msg;
if(PeekMessage(&msg, AfxGetMainWnd()->m_hWnd, 0, 0, PM_REMOVE))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}--- :beer: Hakuna-Matata :beer: It means no worries for the rest of your days... It's our problem free, Philosophy :jig: "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."
Its a long time ago I wrote a message loop but this looks good. But do this in a while loop (because you should process all messages in the queue) till PeekMessage returns 0 (so no more messages are available). And maybe you should process the WM_QUIT message.
Greetings Covean
-
Is the following snippet of MFC code similar to the DoEvents() functionality in Visual Basic?
MSG msg;
if(PeekMessage(&msg, AfxGetMainWnd()->m_hWnd, 0, 0, PM_REMOVE))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}--- :beer: Hakuna-Matata :beer: It means no worries for the rest of your days... It's our problem free, Philosophy :jig: "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."
I don't know about all details of the DoEvents in VB but this code is doing something similar: it allows you to let the UI not freeze even if you are doing lenghty calculations. But everything should be explained quite in details in the article I gave you.
Cédric Moonen Software developer
Charting control [v3.0 - Updated] OpenGL game tutorial in C++ -
Is the following snippet of MFC code similar to the DoEvents() functionality in Visual Basic?
MSG msg;
if(PeekMessage(&msg, AfxGetMainWnd()->m_hWnd, 0, 0, PM_REMOVE))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}--- :beer: Hakuna-Matata :beer: It means no worries for the rest of your days... It's our problem free, Philosophy :jig: "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."
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
-
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
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 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
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
-
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
Rozis wrote:
every thread has its own message-queue.
True: though on 16-bit Windows [^]... :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] -
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
<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
