I have a typical dialog box program. The process priority can be set to idle, but the Task Manager is still reading at 100%. How can I force the dialog to not consume procesor resources - even if idle? If it is just on the screen and not doing anything I don't want it's message loops to be such a pig. :)
add a Sleep call? :/
Where? Windows manages the message loop for the dialog box - I just respond to the messages for the dialog. I feel that I'm missing something really basic maybe? I know how to do this with my own message loop, but I was curious how to do this with a dialog box (DialogBoxParam).
It is inconceivable to have a constant 100% cpu usage in a message loop. GetMessage waits for a message and consumes practically no resources while it waits, how many messages can possibly be sent to your dialog if it is idle, maybe WM_PAINT and a few other system wide messages. Are you using Win98SE ? the system monitor for 98SE has a problem with getting stuck on 100%, MS says to ignore it (Q227131)
If its your average Dialog Box then perhaps you're returning nonzero to something you shouldn't be?
Sorry if I'm stating the obvious here :) .
Sorry if I'm stating the obvious here :) .
E?in, I think you might be on to something. I should return zero for all the messages I handle? Thanks, I'll look into it further.
I'm using Win2K/XP.
I'm using Win2K/XP.
The WndProc and messageloop for a dialogbox is not the same as for a Window.
Maybe you're doing something to cause the system to send repeated messages. Such as invalidating a region of the window before returning from a WM_PAINT.
xor eax,eax before ret
I think its supposed to be zero for everything you don't handle, nonzero for everything you do. The only exception is WM_INITDIALOG the return value of which has to do with control focus.
I think iblis could be on to something as well.
I think iblis could be on to something as well.
The WndProc and messageloop for a dialogbox is not the same as for a Window.
Ofcourse they aren't, one is application based the other is internal but they both use GetMessage/DispatchMessage otherwise MS would have designed their dialogs to use 100% resources. My point is that they are designed with an internal version of the message loop that has to be the functional equivalent to the standard message loop. That is that it will wait for a message before stepping the loop and should require little or no resources while it waits. I have never seen an idle dialog take more than 1 or 2 % processor usage, it has to be something other than the message loop. Maybe invalidating the dialog in the WM_PAINT message or something like that.
donkey, thanks - that is exactly what I wanted to confirm - I am doing something wrong. That is very logical and of course, what I assumed, but I needed confirmation.
E?in, I've ensured that TRUE is returned on all messages processed by the dialog, and FALSE otherwise. Also, I did fix a stack imbalance - funny how the program even works with all the bugs. :)
iblis, of all the advice this one is left to debug - working on it now...
Thanks everybody!
E?in, I've ensured that TRUE is returned on all messages processed by the dialog, and FALSE otherwise. Also, I did fix a stack imbalance - funny how the program even works with all the bugs. :)
iblis, of all the advice this one is left to debug - working on it now...
Thanks everybody!
maby post your code so we can help you.
maby post your code so we can help you.
I figured it out - !what a dummy I am! - it is the thread I created (duh). There is no error with the dialog box. What I did was run OllyDbg and set a break point on the dialog proc, ran the program until it started grabing 100%, and then I noticed the breakpoint on the dialog proc wasn't stopping - I fell on my face big time. :)
...let me go fix my thread now. :o
I'm sure you already know, but a quick test with WinSpy should show you roughly what window messages are being spammed to your dialog window.
Edit: Posted this before I saw your recent reply.
Edit: Posted this before I saw your recent reply.