|
Why isn't it useful?
A dirty trick would be
union type_Array
{
unsigned char _c[8];
buf0 msg0;
buf1 msg1;
} ;
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]
|
|
|
|
|
isn't usefull either because I have to modify the driver. The upper section until // /// UP is the Driver .. No changes possible
// X 8 times
I cannot modify!
because of these individual buffers of the driver ... insted of writing a SINGLE! Processing message function - for all messaging (involving these individual buffers) (it is the same code) - I have a dozen function making same thing.
Inside them I refer to buffers like message0._c[(i=1,n)]= value; , next function message1._c[(i=1,n)]= value etc.
If i would have an ARRAY of message0, message1, I would write a single function.
with my previous code I would refer these buffers with Vector[0].msg0._c[0]=1; //ok // not usefull
But how do I put in the code line section msg0? the above line would be in a for.
Maybe I was more clear explaiing my problem this time.
I think the problem here is, basically I have a union inside a union.
|
|
|
|
|
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 | [beer]](https://codeproject.global.ssl.fastly.net/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://codeproject.global.ssl.fastly.net/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."
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
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)
(