C++ - Totally suspend windows application

Question

I am developing a simple WinAPI application and started from writing my own assertion system.

I have a macro defined like ASSERT(X) which would make pretty the same thing as assert(X) does, but with more information, more options and etc.

At some moment (when that assertion system was already running and working) I realized there is a problem.

Suppose I wrote a code that does some action using a timer and (just a simple example) this action is done while handling WM_TIMER message. And now, the situation changes the way that this code starts throwing an assert. This assert message would be shown every TIMER_RESOLUTION milliseconds and would simply flood the screen.

Options for solving this situation could be:

1) Totally pause application running (probably also, suspend all threads) when the assertion messagebox is shown and continue running after it is closed

2) Make a static counter for the shown asserts and don't show asserts when one of them is already showing (but this doesn't pause application)

3) Group similiar asserts and show only one for each assert type (but this also doesn't pause application)

4) Modify the application code (for example, Get / Translate / Dispatch message loop) so that it suspends itself when there are any asserts. This is good, but not universal and looks like a hack.

To my mind, option number 1 is the best. But I don't know any way how this can be achieved. What I'm seeking for is a way to pause the runtime (something similiar to Pause button in the debugger). Does somebody know how to achieve this?

Also, if somebody knows an efficient way to handle this problem - I would appreciate your help. Thank you.

Answer 1

It is important to understand how Windows UI programs work, to answer this question.

At the core of the Windows UI programming model is of course "the message" queue". Messages arrive in message queues and are retrieved using message pumps. A message pump is not special. It's merely a loop that retrieves one message at a time, blocking the thread if none are available.

Now why are you getting all these dialogs? Dialog boxes, including MessageBox also have a message pump. As such, they will retrieve messages from the message queue (It doesn't matter much who is pumping messages, in the Windows model). This allows paints, mouse movement and keyboard input to work. It will also trigger additional timers and therefore dialog boxes.

So, the canonical Windows approach is to handle each message whenever it arrives. They are a fact of life and you deal with them.

In your situation, I would consider a slight variation. You really want to save the state of your stack at the point where the assert happened. That's a particularity of asserts that deserves to be respected. Therefore, spin off a thread for your dialog, and create it without a parent HWND. This gives the dialog an isolated message queue, independent of the original window. Since there's also a new thread for it, you can suspend the original thread, the one where WM_TIMER arrives.

Answer 2

Don't show a prompt - either log to a file/debug output, or just forcibly break the debugger (usually platform specific, eg. Microsoft's __debugbreak()). You have to do something more passive than show a dialog if there are threads involved which could fire lots of failures.