Application Idle - Good or bad practice?

[Udi]

Hi All,
What do you know about the Application.Idle event?
When is it a good practice to use it and when should I not use it?
I know it fires when the app message queue is empty, and that this
happens a lot.
But if I register many handlers on this event, what impact will it have
on my application?
Is it true to say that it doesn't impact my application performances
becuase the queue is empty anyhow?
Thanks!

 

[Willy Denoyette [MVP]]

| Hi All,
| What do you know about the Application.Idle event?
| When is it a good practice to use it and when should I not use it?
| I know it fires when the app message queue is empty, and that this
| happens a lot.
| But if I register many handlers on this event, what impact will it have
| on my application?
| Is it true to say that it doesn't impact my application performances
| becuase the queue is empty anyhow?
| Thanks!
|

It depends largely on what your handlers are doing, as long as they don't
block the message pump you are safe, but once you are start computational
intensive tasks you might disturb the message pump and this will have an
impact on the responsiveness of the main UI.


Willy.

 

[Udi]

Thanks Willy,
So just to understand, if I have lots of very short handlers I'm ok?
Do they have lower priority than the main UI messages?
(What happens if i have registered say 5 handlers on App.idle, 3 are
dealt, and than comes a message from the main UI? Will the remaining 2
handlers be executed first on the next idle? will they be ignored?)
- Or, once the app.idle is fired, it will execute all of it's handlers,
and only after executing all of them it returns the control back to the
main UI queue?

 

[Tom Porterfield]

Thanks Willy,
So just to understand, if I have lots of very short handlers I'm ok?
Do they have lower priority than the main UI messages?
(What happens if i have registered say 5 handlers on App.idle, 3 are
dealt, and than comes a message from the main UI? Will the remaining 2
handlers be executed first on the next idle? will they be ignored?)
- Or, once the app.idle is fired, it will execute all of it's handlers,
and only after executing all of them it returns the control back to the
main UI queue?

The latter is my understanding of how it works. Once it fires, it will
execute all handlers before returning. Note also that this fires just
before the thread becomes idle.

 

[Willy Denoyette [MVP]]

| Thanks Willy,
| So just to understand, if I have lots of very short handlers I'm ok?
| Do they have lower priority than the main UI messages?
| (What happens if i have registered say 5 handlers on App.idle, 3 are
| dealt, and than comes a message from the main UI? Will the remaining 2
| handlers be executed first on the next idle? will they be ignored?)
| - Or, once the app.idle is fired, it will execute all of it's handlers,
| and only after executing all of them it returns the control back to the
| main UI queue?
|

The handler runs on the UI thread, that means that it runs at the same
priority and as long as your handler runs, it blocks the processing of new
messages. Note that it's possible to interrupt the handler by pumping the
queue (DoEvents or similar) so that you don't block the message queue while
running time consuming handlers (reminds me of 16 bit Windows, shiver...).

All handlers will get executed supposed no new messages are waiting in the
system queue.
When an handler returns, the framework code pumps the queue and when a new
message arrived, it will handle that message (subject of message priorities
AFAIK) before invoking the next handler.

Willy.