This question already has answers here:
Why does closing a console that was started with AllocConsole cause my whole application to exit? Can I change this behavior?
(4 answers)
Closed 9 years ago.
I needed to be able to output to a console from my GUI-based app written in C++, so I chose to use the AttachConsole(ATTACH_PARENT_PROCESS) API and this code to do so. That method works great, except that when I start my GUI app from a command prompt window the GUI app starts just fine but when I close the command prompt window my GUI app is terminated (note, not closed, but terminated.) Is there any way to prevent this app termination?
You can prevent your application from closing when somebody closes the console window.
It involves calling SetConsoleCtrlHandler to set a HandlerRoutine that intercepts those events.
If you want the console window to close, but leave your app running, you might be able to call FreeConsole in your HandlerRoutine. If that doesn't work, then handle the message to prevent the console window from being destroyed, and set a flag or a timer that will cause your app to call FreeConsole after returning from the handler.
As I recall, you can't prevent the window from closing when the user hits the X on the window. What I did to prevent that is modify the window menu. See http://blog.mischel.com/2008/07/14/going-too-far-back/ for some details.
I was able to resolve this issue by attaching to the parent console right before posting the text to the stdout stream and then by detaching from it. This way the text is posted alright and the console remains separate from my GUI app.
Here's the MFC/C++ class with the full implementation for those who want to use it.
Related
I am working on a TCP server that I'm developing on CLion under Windows 10.
I would like my program to be able to end properly, when I click on "stop" my program. I thought CLion was sending a signal, but after trying to catch them all, it looks like it does not.
So my question is, how does CLion stop running the program? Is it possible to detect it within the program?
Thank you in advance.
I found my answer here.
According to this link, signals are actually used :
Click this button to terminate the current process externally by means
of the standard shutdown script. Clicking the button once invokes soft
kill allowing the application to catch the SIGINT event and perform
graceful termination (on Windows, the Ctrl+C event is emulated). After
the button is clicked once, it is replaced with icon run tool window
kill indicating that subsequent click will lead to force termination
of the application, e.g. on Unix SIGKILL is sent.
I have just got this problem for a few days. Before, I've always thought that letting the program exit by returning from main and clicking close the console window is the same way to end the program.
However, I've found that they are different. Since my program opens a camera which is an object. And closing the console windows does not destroy or clean up the object. So the next time I have error to open the camera again
I just need a confirm if this is true?
Then why only until now I can see the problem?
Closing a console window in Windows, kills the running program (or stack of running programs). Unless it has registered a handler for this event, it gets no chance to clean up. If you want solution, register a handler.
Hm, consulting the documentation, wait a few secs…
OK, look up SetConsoleCtrlHandler.
Closing a running console application will kill the process, not giving you the chance for any clean up code. I guess you could hook a windows message loop to trap the WM_CLOSE message and do proper cleanup, but at the end of the day, you just shouldn't kill the process.
I have a windows application which invokes CreateProcess and then it exits. The process being invoked displays console and GUI windows at startup. I would like to hide the console window of the child process right when it starts.
More info:
Process is NOT started with DETACHED_PROCESS flag.
If injecting code with FreeConsole() to the remote process is the only way (I'm looking for a better one), is it not going to cause trouble with over-sensitive anti-viruses?
You can use the CREATE_NO_WINDOW flag to start a console application without a console window. It's not the same as it being hidden, but it sounds like it's what you want.
I want a C++ program to execute a function when I close manually the console.
I made a C++ program that test a password and if it isn't correct make the windows to log off.
But if I close the console from the "X" button nothing happens and I want to make windows to log off too if the console is closed from "X" button?
I tried _onexit_t oe() function but it doesn't help me.
So there is a method to do that or to hide the bar which contains the "Minimize", "Maximize" and "Close" buttons?
Assuming you mean the normal textual console window, you can register your own event handler via SetConsoleCtrlHandler and watch for the events CTRL_C_EVENT, CTRL_BREAK_EVENT, CTRL_CLOSE_EVENT, CTRL_LOGOFF_EVENT, CTRL_SHUTDOWN_EVENT, etc.
I guess the question says it all, but, what happens if someone closes a c++ console app? As in, clicks the "x" in the top corner. Does it instantly close? Does it throw some sort of exception? Is it undefined behavior?
Closing a c++ console app with the "x" in the top corner throws an CTRL_CLOSE_EVENT which you could catch and process if you set a control handler using the SetConsoleCtrlHandler function. In there you could override the close functionality and perform whatever you wished to do, and then optionally still perform the default behavior.
I imagine that the console process just gets unceremoniously killed by the OS. If you want to trap this event and do something it looks like the SetConsoleCtrlHandler function is the way to do it.
See also:
How to handle a ctrl-break signal in a command line interface
Console Event Handling
On Linux and other Unix systems, the console runs as a separate process. As you close the shell, it sends the SIGHUP signal to the currently active process or processes that are not executed in the background. If the programmer does not handle it, the process simply terminates. The same signal is sent if you close the SSH session with a terminal and an active process.
SIGBREAK is raised on Windows.