I modified an MFC example for OpenCascade, adding some functionality (it was the HLR example). The application uses the document/view architecture, with document class doing most of the work.
Some of the new functions don't require a GUI, so the program exits before the GUI is opened, which I perform by calling exit(0)
from a CDocument specialization.
My problem is, for our workflow, the MFC application will be called from the Windows command line. As soon as it's called, it returns control back to the shell and continues merrily along in the background, whether it opens a GUI or not. What I need the application to do is to block from the command line, whether the GUI is open or not.
I've been reading up on CWinApp, and CMDIFrameWnd, but if you can make your application block from the command line, I can't figure out how to do it.
If you set your executable to be a console application with the linker option /SUBSYSTEM:CONSOLE the command line will block till the application exits. Remember that A console application can have a windows GUI.
Setting the linker setting /SUBSYSTEM:CONSOLE does have one problem if you do that as a linker setting you will have to adjust entry point to be main() instead of winmain. In the following thread there are a few a workarounds for that (thanks for Ulrich Eckhardt mentioning the entry point) :
Visual Studio 2012 C++ Standard Output
There is also a second negative of this approach. If the program is not run from a console window the application will create a console window for you. This may confuse users.
You can't. EXEs are marked as either console or windows programs and if it's a Windows program control is handed over to the Windows manager and the console will keep running.
Your best bet is to create a small console app that calls CreateProcess
to launch the Windows app and then simply WaitForSingleObject
on the hProcess handle for it to finish.
More technical information on why it's not possible is available on the The Old New Thing blog here:
http://blogs.msdn.com/b/oldnewthing/archive/2009/01/01/9259142.aspx