Force closing an MFC GUI

Question

I have a process loading a UI provider via dll and another system resource that provides functionality which I forward to the UI via callbacks.

In some cases, the underlying resource faults while the (MFC) UI is showing. I'm in a discussion with with the person in charge with the UI about the appropriate way to shut down the UI in such cases.

Some details: since I provide the callbacks I can listen to faults coming from the resource and call an async callback to shutdown the UI (or otherwise raise an event), or possibly I can alter the return codes from the callbacks to signal an error that has occurred.

The person in charge is insisting (for no reason) that shutting down the UI is bad practice. But as far as I can tell, the UI listens to shutdown events anyway, from the user and other sources maybe, so what's the difference if I'm telling it to close?

If this is not entirely clear let me rephrase... Given that you called an MFC GUI and the underlying logic is now invalid, what is the proper way to signal it to close?

Answer 1

If I understand well, you intend to implement an error-recovery strategy which closes the UI if something goes wrong there and relaunch it, hoping for a better outcome.

Such an antibugging approach could be very effective if the UI would be in an independent process. Terminating the process using TerminateProcess() would then let the OS to clean the mess and release the resources even in the most adverse situations. This would let you start again, hoping that the error will not reproduce too early.

Unfortunately your design seems to be based on a UI provider in a DLL. This would mean that your MFC UI runs in the same process as your application and in the same address space. So if the UI screws something up, you could try to end it and restart it, but you have no guarantees about proper release of all the resources and come back to a stable situation:

• if the MFC is run is a distinct thread, you could get rid of it if as explaned here. This could lead to satisfactory results for example if your thread would be stuck in some endless loop or so. But this approach would not work if the thread could corrupt memory.
• you could also close the UI either calling the closing functions as explained here, or, better, sending a WM_CLOSE message as explained here, which should cause UI to end its event loop. Again, this approach would not work if the UI would corrupt memory or if it leaks resources such as paintbrushes or other windows32 critical resources.

As you see, in your context this recovery strategy has only limited benefits. If you have a bug freezing your UI from time to time there are chances that some memory gets corrupted somewhere. In addition, such error recovery is only a work around to keep the things up running. The user experiencing this kind of restart would certainly be happy if it happens once a year, but would quickly lose confidence if if it's every day.

You are not wrong in your approach, trying to minimize the effects of the bug, but your colleague is not wrong either, when he'd expect the bug to get eliminated. personally, I would invest in the latter first.