Greetings,

Does anyone know what WaitForInputIdle is actually triggering off of? I
know it is typically used to detect when a spawned process is ready to
get messages (i.e. when the queue is created and it has blown through
most of the startup messages and is "waiting for input").

But the docs clearly say that "The WaitForInputIdle function can be used
at any time, not just during application startup" so it obviously has
uses beyond the common idiom.

I am trying to use it to detect when my own applications message queue
is empty from another thread (i.e. a different thread than the one with
the main PeekMessage loop).

My second thread calls WaitForInputIdle and then does some action I want
to happen often, but not so often as to plug up the main message queue
(this action generates lots of messages and WM_PAINTs). It works great
on some machines, but on others, it appears that WaitForInputIdle is
returning too quickly. In particular, it seems to be returning before
all WM_PAINT and such low priority messages have been completed. Thus
the second thread floods the message queue with messages and WM_PAINTs
and so forth never happen.

Does it only check for user generated messages (a problem for me), or is
it looking for an empty queue (this is what I am wanting).

Best regards,

Tom Udale

On May 7, 2:04*pm, Tom Udale <a...@bbb.com> wrote:


Hi,

You can use the following APIs to create a thread and set its priority
to THREAD_PRIORITY_IDLE, then this thread can be waken up only
when the system is idle, and it will execute your code:

CreateThread()

SetThreadPriority()

http://msdn2.microsoft.com/en-us/library/ms682453.aspx

http://msdn2.microsoft.com/en-us/library/ms686277.aspx

http://msdn2.microsoft.com/en-us/library/ms685100.aspx

Kellie.

Dear Kellie,

Thank you very much for your suggestion. I actually just tried this
myself and it does not change the behavior at all - although I think it
is a better approach. Thus I think that something else is going on
here. I am going to instrument the program with some debug statements
to try to see what is actually happening.


Best regards,

Tom

On May 8, 8:20*am, Tom Udale <a...@bbb.com> wrote:


Hi Tom,

Well, if your thread have a window with a modal dialog box,
you can receive the following Windows notification when
entering an idle state.

http://msdn.microsoft.com/en-us/libr...22(VS.85).aspx

Kellie.

Dear Kellie,

Thanks for that. WM_ENTERIDLE is a second approach we have been
thinking about. It is indeed my "plan B" if this does not pan out.

In my investigation yesterday I discovered a bug in my code that is
allowing my idle thread to run a lot more often than I thought it should
have been. That could be the bulk of the problem.


Best regards,

Tom

In article <ksudnVpIkvMAhL_VnZ2dnUVZ_tKinZ2d@comcast.com>, aaa@bbb.com
says...

[ ... ]

First you should realize that under normal circumstances, a WM_PAINT
message is never put into the message queue at all. Rather, there's a
bit associated with the window that's set when there's an invalid area.
When you call GetMessage, and there's no message in the queue, and the
bit is set, it synthesizes a WM_PAINT for you to process. As such, just
checking for an empty queue won't guarantee that there isn't painting
waiting to be done.

To answer your original question, when you call WaitForInputIdle, it
waits until the thread the created the first window in the specified
process has no input waiting to be processed. Given how WM_PAINT works,
it may well NOT wait until all invalid areas in the target window have
been validated -- though I've never tried to figure that out.

--
Later,
Jerry.

The universe is a figment of its own imagination.