catch ctrl-C in console window

[Björn]

Hi,

I have a problem with a windows app that opens a console window in a separate thred. To try to catch ctrl-C in the console window I have called SetConsoleCtrlHandler and sure I get into this routine returning 1 meaning ctrl-C processed.

My problem is that the console window is holding at a READ statement waiting for input from the user. Eventhough I have processed the ctrl-C in the handler routine it gets read by the READ which returns with ERR set causing my app to close.

How can I avoid this behaviour from READ?

/bjrn

[Björn]

Sorry that should have read END not ERR.

/bjrn

[Steven_L_Intel1]

I don't think you can change it - the I/O library is waiting for a ReadFile to complete and Windows is returning an EOF status when ^C is pressed. Perhaps you can use IOSTAT to detect that, note that your handler was callled, and restart the read or whatever you want it to do.

What WOULD you like the console program to do in this case?

[drgfthomas]

If I've understood the problem, the CTRL_C_EVENT in you handler is masked, the READ kicks in andEND.So in that case let the handler unmask the CTRL_C_EVENT by issuing a FreeLibrary and returning FALSE.

[Björn]

Hi Steve and Garry,

thanks for your input. What I WOULD like to happen is that the CTRL_C_EVEN event goes away and does not affect the READ of the consol app. I have read up on FreeLibrary but unfortunately it is not clear to me how to get its module handle argument. GetModuleHandle is hinted but then again I don't understand how to get its argument. Isit to be the name of my own executable or something else?

regs/Bjrn

[drgfthomas]

Bjrn,

I should have said FreeConsole (which returns a BOOL) but anyways it doesn't help. An internal read (*,*) is regarded as a programming error that expects input from stdin and not a Ctrl_C_EVENT. Not even SEH can help in this case: traceback issues a report when it occurs and the app closes by FRT's design. Now I understant Steve's reference to IOSTAT.

BTW,

Use

....

hwnd=FindWindow(NULL,ColsoleTitle);

SetCtrlHandler(hwnd); //to set up your handler

BOOL WINAPI handler(DWORD dwCtrlType)
{

switch(dwCtrlType)
{
case CTRL_C_EVENT:
break;

  case CTRL_BREAK_EVENT:
break;

case CTRL_CLOSE_EVENT:
  break;

case CTRL_LOGOFF_EVENT:
return(FALSE);
   break;

case CTRL_SHUTDOWN_EVENT:
 return(FALSE);
   break;

default:
   break;
 }

return(TRUE);
}

void SetCtrlHandler(HANDLE hConOut)
{
 BOOL status;

 // Set custom handler for process
 status = SetConsoleCtrlHandler(handler, TRUE);
 //_cputs("Handler set
");
 
 return;
}

or to

//Show/hide the console for debug/release configuration
//#ifdef _DEBUG
//statConsole = ShowWindow(hwnd,SW_NORMAL);
//#endif

//#ifdef NDEBUG
//statConsole = ShowWindow(hwnd,SW_HIDE);
//#endif

[jimdempseyatthecove]

Your Ctrl-C handler should suck in the ^C char using the C Runtime Library getch function. Your handler can also set a CtrlCdetected flag that is visible to other routines that need to know.

You will have to decide how to handle ^C intermixed with text input.

case CTRL_C_EVENT:
while(kbhit()) getch();
CtrlCDetected = TRUE;
break;

The above implements the rule "Control-C clears keyboard buffer and sets CtrlCDetected = TRUE"

Jim

[Björn]

thanks folks,

I will investigate your suggestions.

Bjrn