|
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
|
|
|
|
|
Rozis wrote: every thread has its own message-queue.
True: though on 16-bit Windows [^]... 
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]
|
|
|
|
|
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?
|
|
|
|
|
adjust the positions of all child control properly
|
|
|
|
|
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.
---
![Beer | [beer]](https://www.codeproject.com/script/Forums/Images/beer.gif) Hakuna-Matata
It means no worries for the rest of your days...
It's our problem free, Philosophy
![Jig | [Dance]](https://www.codeproject.com/script/Forums/Images/jig.gif)
"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."
|
|
|
|
|
Here[^] is one of the best article I've read about threading. It will answer a lot of your questions.
|
|
|
|
|
|
|
|
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?
|
|
|
|
|
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. <
|
|
|
|
|
|
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
|
|
|
|
|
Isn't that (being scheduled) the normal thread beahviour?
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]
|
|
|
|
|
i changed the thread priority to HIGHEST, but it didi not help.
|
|
|
|
|
Simply don't do that. It is normal for threads being scheduled.
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]
|
|
|
|
|
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
|
|
|
|
|
True but it really depends on how those 3-5 seconds come out? Are they just a OP impression? How did she measure them?
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]
|
|
|
|
|
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
|
|
|
|
|
use function Sleep(n_time).
|
|
|
|
|
Uh?!
OP missed?
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]
|
|
|
|
|
I prefer you to read chapter 2. Processes and threads from "Modern Operating Systems" by Andrew S Tannenbaum.
It will be useful for you.
Величие не Бога может быть недооценена.
|
|
|
|
|
Can you please post your threads code to see if they are waiting for some reason.
Edit: Did some typo.
Greetings
Covean
|
|
|
|
|
void CMyThread::ThreadStart()
{
if (m_pSelThread != NULL) // CWinThread* m_pSelThread;
{
if (::WaitForSingleObject(m_pSelThread->m_hThread, 0) != WAIT_OBJECT_0)
return;
delete m_pSelThread;
m_pSelThread = NULL;
}
m_pSelThread = AfxBeginThread((AFX_THREADPROC)ThreadFunction, this, THREAD_PRIORITY_NORMAL, 0,CREATE_SUSPENDED);
m_pSelThread->m_bAutoDelete = FALSE;
m_pSelThread->ResumeThread();
}
UINT CMyThread::ThreadFunction
(
LPVOID param
)
{
while(!bTerminate) // bool bTerminate
{
if ((::WaitForSingleObject(m_Sel_End_Event, 0) == WAIT_OBJECT_0))
{
bTerminate = true;
continue;
}
}
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
(