0

* This is not a duplicate question. The other question title does not match its body! The other question title should be: "how do you send a SIGINT from one Windows process to another". It has nothing to do with Ctrl-C and he IS using Console applications. *

I have a normal windows application, it is not using MFC nor is it a console application. I need the typing of CTRL-C to send SIGINT to my program rather than a KEYDOWN event. From my testing this does not seem to just happen by default. How do I tell Windows (7) to send my process SIGINT when someone types CTRL-C when my application window has the focus?

The closest thing I found was SetConsoleCtrlHandler(null, false); but that doesn't work, probably because it isn't a console application.

The answer may be to make it a console application with an invisible console. But I do not know what the implications of that would be to my current code. I am hoping there are a simple couple of calls that set this up without going full console?

Bill Bouma
  • 1
  • 2
  • possible duplicate of [Can I send a ctrl-C (SIGINT) to an application on Windows?](http://stackoverflow.com/questions/813086/can-i-send-a-ctrl-c-sigint-to-an-application-on-windows) – durron597 Sep 04 '15 at 01:42
  • 2
    If you want a non-console program to do something when you press CTRL-C, you have handle the keyboard event and then do that something. Windows doesn't have signals, and any SIGINT support in console applications is just a crude Unix emulation provided by the C runtime library, not Windows itself. Note that most people wouldn't expect CTRL-C to terminate a GUI program, they'd expect it to copy the selected text into the clipboard or something similar. – Ross Ridge Sep 04 '15 at 01:43
  • What specifically do you want to do that makes SIGINT seem like a good solution? Whatever you were going to do in the signal handler, why can't you do the same thing when you receive a CTRL-C keyboard event? Or do you just need advice on how to catch the keyboard event? – Harry Johnston Sep 04 '15 at 02:31
  • My application actually is a console that uses opengl for all graphics components, even text. It already catches all keyboard events, of course. It works fine. The problem is that when I run a command there is no way to break it and get back to the prompt. The code is actually more complicated than this, but that is the basic. I have been coding for 36 years now. Mostly not Windows, though. – Bill Bouma Sep 04 '15 at 16:54
  • There must be a way that the windows Console junk does this. Do they always launch into a sub-process or separate thread? I don't like doing that for this app. All I need is for the OS to send me the SIGINT like it is supposed to. (Why can't I hit at this site without it posting? Annoying!) – Bill Bouma Sep 04 '15 at 16:58
  • Are you trying to make control-C interrupt something that your own application is doing, or did you want it to interrupt a child process? Do you want to run a SIGINT handler function, or just kill the process? – Harry Johnston Sep 04 '15 at 21:57
  • Harry, there is only one process. You type a command at a prompt and the thing goes off to do some stuff. When it comes back you type it some more commands. Note that a lot of that stuff may be to process other events including keyboard events. The program already has a handler for SIGINT that seems to work right if I raise it from a software hack. It stops whatever is running and returns to the prompt. – Bill Bouma Sep 06 '15 at 14:42
  • OK, so you've already got logic to process window messages, and also some sort of interrupt logic, implemented as a signal handler. There's nothing special about the context in which the signal handler runs, so when you see a control-C in the message queue, you *should* be able to simply call the signal handler function directly, or call `raise(SIGINT)` if you prefer. Am I missing something? – Harry Johnston Sep 06 '15 at 21:17

0 Answers0