Short version: How do I pump for messages while at a particular stack frame so I can wait for a custom dialog to return while blocking, just like Window.ShowDialog(). Ideally avoiding async or multiple threads.
I am creating a custom Notification Dialog for my application which supports a set of different display modes.
It can be used as a blocking popup, exactly like MessageBox.Show, by using Window.ShowDialog(). It can also act as a non-blocking message box by using the regular Show command.
However, I want to have third mode, where the dialog can be shown with a non-blocking call, but then later another call will block until the user closes the dialog. This is so I can let the user know earlier on when they will need to do something, but when the time comes, if the user hasn't already dismissed it the main application thread will block.
Keep in mind I’m not using Async with this.
Basically: NotifyDialog.ShowNonBlocking(“please remove the device and click OK.”); //do stuff, wait for processing to complete.
//processing now done, we really need to get rid if the device before the next thing starts. NotifyDialog.BlockUntilClosed(); //disables main window, starts nested message pump here.
I first wrongly assumed that creating a new Window would create a new thread and Dispatcher queue automatically, so I tried using a condition. Turns out that it doesn't create a new thread. I assumed this because Window.ShowDialog() blocked while the new dialog was shown, but as far as I can tell now it just disables all other windows, and kind of hijacks the message pump (I assume that the stack would look something like main -> message pump -> event that lead us to the ShowDialog() call -> new, hijacked message pump loop.)
Anyway, I would like to reproduce this behavior manually so in my NotifyDialog.BlockUntilClosed() call I can hijack the message pump, disable my main window, and wait for the window to close.
If this isn't possible, I’m going back to the plan of launching the window on a new thread, which there seems to be a handful of articles explaining.
I want to keep this easy to use, so I don't want to depend on closed event callbacks that the consumer would need to use, and my application isn't using Async right now, so I can't await the result.