I am trying to use the code in this article that lets you know when your app is idle..
This code works great if your application has only one form. You call A
Pardon me for asking, but why are you going through all this insane amount of trouble for something this simple? Looking at the article you linked, all it does is start a timer and reset it every WM_KEYUP
, WM_MOUSEMOVE
or WM_LBUTTONUP
event.
You can achieve the same thing by overriding WndProc
or PreProcessMessage
in your form and letting it do the timer reset thing. You can even make a base form (*) that does the timer/resetting thing and derive all your forms from it. And for a real global solution, make the timer static.
(*) Don't mark it as abstract or the forms designer will throw a hissy fit.
I can explain the behavior, though maybe not offer a direct solution.
When you call Show on any Form, the Form's events get handled by the default message pump (which gets set up with the call to Run). When you call ShowDialog, the target Form gets its own, separate message pump.
Now the filter you've added resides in the main message pump and it's looking at all messages there, but the ShowDialog call circumvents that - messages send to the dialog will never reach the filter.
Now we did add the Application2.ShowDialog call as an attempt to work around this issue, but to be honest, while I wrote the entire Application.Run/IMEssageFilter implementation, I did not do the ShowDialog workaround and I really don't know how well it was implemented. Based on your report I'd hazard a guess of "not well" though it really is not a simple problem to solve. The root of this issue is that the SDF doesn't control what happens in the BCL when you call Show and ShowDialog - we're simply trying to sit above it and provide the best behavior we can. In this case it's problematic.
Can you, by chance, not use a call to ShowDialog, but instead just use Show coupled with something like keeping the form TopMost? This would allow the filter to get all messages for the pseudo-dialog. The other option I can think of right offhand would be a base class for Dialogs that would notify back to the filter mechanism, but that starts getting real challenging to control.