Question

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 Application2.Run(myOnlyForm) on it and all messages get routed through the filters in Application2.

However if at any point you call mySecondForm.ShowDialog() that dialog does not get its messages filtered through Application2.

Is there any way (with out bad side effects) to get the messages on mySecondForm to go through the `Application2′ event filters?

I have tried:

1. Changing mySecondForm.ShowDialog to Application2.Run(mySecondForm).
   • This causes the window to not clean up when it goes out of scope and to not show when needed.
2. Changing mySecondForm.ShowDialog to Application2.ShowDialog(mySecondForm).
   • This causes the main menu on mySecondForm to not work (clicking has no effect, just beeps).
     • This seems like the one I should be using, but I kind of need to have menus on my screens. It seems that this is a common problem with OpenNETCF.
     • The menu item is not broken. Using the hot key for the menu still works. Just tapping the menu does not work.
3. Changing mySecondForm.ShowDialog to Application2.ShowDialog(mySecondForm, true) (true = clean up the dialog box).
   • This this does not work because I need access to the dialog box after it closes some times.

Ideally I would like a way to attach a form to the message abilities of Application2.

But I welcome any suggestions.

---

Edit:
Based on the suggestion for ctacke this is what I have done:

public static DialogResult ShowDialog2(this Form form)
{
    //form.Activated += InsertMenu;
    //Application2.ShowDialog(form);
    form.Show();
    try
    {
        do
        {
            Application2.DoEvents();
        } while (form.Visible);
    }
    catch (ObjectDisposedException)
    {
        // This just means that the form was closed.  Not a big deal.
    }
    return form.DialogResult;

}

I end up calling ShowDialog2 rather than ShowDialog

Answer 1

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.