1

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.

HeywoodFloyd
  • 166
  • 1
  • 12
  • 1
    I would make it a console application with the /SUBSYSTEM:CONSOLE linker setting. – drescherjm Jun 20 '13 at 16:06
  • I think that will also implicitly change the entry point to main(), so you will need `/entry:WinMain` or something like that in addition in the linker settings. – Ulrich Eckhardt Jun 20 '13 at 16:12
  • 1
    I have a few options for that problem here: http://stackoverflow.com/questions/13840942/visual-studio-2012-c-standard-output/13841522#13841522 – drescherjm Jun 20 '13 at 16:16
  • Thanks for the recommendations about compiling/running as a console application. We're just going to call the application from a batch file, which blocks until the application finishes. – HeywoodFloyd Jun 20 '13 at 18:36

3 Answers3

1

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.

Community
  • 1
  • 1
drescherjm
  • 10,365
  • 5
  • 44
  • 64
  • Thanks for all the recommendations about compiling/running as a console application. I'm not worried about confusing the user, but I am worried that a whole bunch of printf debugging statements getting printed out to the console would slow down the application. Do y'all know if this would be a problem? – HeywoodFloyd Jun 20 '13 at 18:08
  • Can't you disable these in your release build or redirect them to a file? – drescherjm Jun 20 '13 at 18:10
  • It is kind of ridiculous that we've got so much printf debugging, but we've got *so* much (some of it contributed by subcontractors) that we're just going with the batch file solution. Purely a cost saving move. – HeywoodFloyd Jun 20 '13 at 19:45
  • So in a regular batch file calling a windows application the app will wait till it closes? Or is there some option to get this to work. Also please post your batch solution as an answer. I would upvote that. – drescherjm Jun 20 '13 at 19:50
  • Thanks [drescherjm](http://stackoverflow.com/users/487892/drescherjm). I was going to post it as an answer, but stackoverflow's prompt about answering your own questions made me feel slightly ashamed. – HeywoodFloyd Jun 21 '13 at 14:11
0

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

snowdude
  • 3,854
  • 1
  • 18
  • 27
0

If you want to block an MFC app (or windowed app, in general) and output to the console (you'll need to AttachConsole() or AllocConsole() first), do your work in InitInstance (or an equivalent method), wait for any threads to complete in ExitInstance, and then run your program from the command line using "start /WAIT <your app> <your options>". You don't need to write a special console app that waits... start does that already.

Keelan Stuart
  • 21
  • 4