Detective work on Application.Idle event.

[Frank Rizzo]

Hello,

I have a dozen 3rd party controls on my form. I am trying to detect
when the application is idle. But even after the mouse and the keyboard
are no longer moving, something is still triggering the Application.Idle
event. There are no Timers on the form (i removed them all after
realizing that WM_TIMER message will cause the event to fire). Anyway,
how can I figure out which control is triggering the application_idle event?

Thanks.

 

[Sean Hederman]

Hello,

I have a dozen 3rd party controls on my form. I am trying to detect when
the application is idle. But even after the mouse and the keyboard are no
longer moving, something is still triggering the Application.Idle event.
There are no Timers on the form (i removed them all after realizing that
WM_TIMER message will cause the event to fire). Anyway, how can I figure
out which control is triggering the application_idle event?

The Applicatiob.Idle event is not sent by any control, but is sent by
Windows when your message queue is empty. You can then use that event to
provide background processing.

 

[Willy Denoyette [MVP]]

Hello,

I have a dozen 3rd party controls on my form. I am trying to detect when
the application is idle. But even after the mouse and the keyboard are no
longer moving, something is still triggering the Application.Idle event.
There are no Timers on the form (i removed them all after realizing that
WM_TIMER message will cause the event to fire). Anyway, how can I figure
out which control is triggering the application_idle event?

Thanks.

Try Spy++ or this Winspy available for download from
http://www.windows-spy.com/ and watch the messages posted/sent to your
visible/hidden windows.

Willy.

 

[Marc Bernard]

Hello,

I have a dozen 3rd party controls on my form. I am trying to detect when
the application is idle. But even after the mouse and the keyboard are no
longer moving, something is still triggering the Application.Idle event.
There are no Timers on the form (i removed them all after realizing that
WM_TIMER message will cause the event to fire). Anyway, how can I figure
out which control is triggering the application_idle event?

Take a look at the API call GetLastInputInfo for idle detection - it sounds
like what you're after.

Marc

 

[Sean Hederman]

Try Spy++ or this Winspy available for download from
http://www.windows-spy.com/ and watch the messages posted/sent to your
visible/hidden windows.

The Application.Idle event is raised when the IMsoComponent.FDoIdle method
is called on ThreadContext. I'm not sue what does the calling, but I suspect
it's the runtime, not window messages.

 

[Willy Denoyette [MVP]]

The Application.Idle event is raised when the IMsoComponent.FDoIdle method
is called on ThreadContext. I'm not sue what does the calling, but I
suspect it's the runtime, not window messages.

I know, OP's description is misleading - <something is still triggering the
Application.Idle >
It should read - something is preventing the Application.Event to be fired -
, simply because some window messages are still arriving on the message
queue(s). Using something like Spy++ makes it possible to trace these
messages and find-out their source.

Willy.