Ctrl handling question

[vefatica]

In a plugin, I set a console ctrl handler. On receiving a signal greater than CTRL_BREAK_ENENT (for example CTRL_CLOSE_EVENT) it saves a buffer to a file with Qprintf() and returns FALSE.

When it's running in 4NTv8, and I "X" the console, it works fine. With TCCv9, it causes "TCC has encountered a problem". I don't get it. My handler should be first in the chain and no one else should be aware of the CTRL_CLOSE_EVENT until it returns FALSE. Rex, do you know what's going on.

 

[rconn]

vefatica wrote:

> In a plugin, I set a console ctrl handler. On receiving a signal greater
> than CTRL_BREAK_ENENT (for example CTRL_CLOSE_EVENT) it saves a buffer
> to a file with Qprintf() and returns FALSE.
>
> When it's running in 4NTv8, and I "X" the console, it works fine. With
> TCCv9, it causes "TCC has encountered a problem". I don't get it. My
> handler should be first in the chain and no one else should be aware of
> the CTRL_CLOSE_EVENT until it returns FALSE. Rex, do you know what's
> going on.

I'd need the source to debug it.

Rex Conn
JP Software

 

[vefatica]

On Sun, 03 Aug 2008 12:34:17 -0500, rconn <> wrote:

>---Quote---
>> In a plugin, I set a console ctrl handler. On receiving a signal greater
>> than CTRL_BREAK_ENENT (for example CTRL_CLOSE_EVENT) it saves a buffer
>> to a file with Qprintf() and returns FALSE.
>>
>> When it's running in 4NTv8, and I "X" the console, it works fine. With
>> TCCv9, it causes "TCC has encountered a problem". I don't get it. My
>> handler should be first in the chain and no one else should be aware of
>> the CTRL_CLOSE_EVENT until it returns FALSE. Rex, do you know what's
>> going on.
>---End Quote---
>I'd need the source to debug it.

Here are the relevant parts. Do you want more? FWIW, I'm using a custom
entry-point and **no** C-runtime stuff (even so, I can built it complaint-free
with VC8).

BOOL WINAPI CtrlHandler(DWORD dwSignal)
{
if ( dwSignal <= CTRL_BREAK_EVENT )
return TRUE;
else
SaveEditBuf(FALSE);
return FALSE;
}

VOID SaveEditBuf ( BOOL bWithBreak )
{
DWORD dwWritten;
WCHAR szText[32768];
GetDlgItemText(hDlg, IDC_EDIT1, szText, 32768);
HANDLE hFile CreateFile(szFileName, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, NULL);
if ( bWithBreak )
Qprintf(hFile, L"ON BREAK QUIT\r\n");
Qprintf(hFile, L"%s", szText);
CloseHandle(hFile);
}

 

[vefatica]

In a plugin, I set a console ctrl handler. On receiving a signal greater than CTRL_BREAK_ENENT (for example CTRL_CLOSE_EVENT) it saves a buffer to a file with Qprintf() and returns FALSE.

When it's running in 4NTv8, and I "X" the console, it works fine. With TCCv9, it causes "TCC has encountered a problem". I don't get it. My handler should be first in the chain and no one else should be aware of the CTRL_CLOSE_EVENT until it returns FALSE. Rex, do you know what's going on.

P.S. If I replace Qprintf() with WideCharToMultiByte() and WriteFile() appropriately, it's OK.

 

[rconn]

vefatica wrote:

> On Sun, 03 Aug 2008 12:34:17 -0500, rconn <> wrote:
>
>
> Quote:
> >---Quote---
> >> In a plugin, I set a console ctrl handler. On receiving a signal
> greater
> >> than CTRL_BREAK_ENENT (for example CTRL_CLOSE_EVENT) it saves a buffer
> >> to a file with Qprintf() and returns FALSE.
> >>
> >> When it's running in 4NTv8, and I "X" the console, it works fine. With
> >> TCCv9, it causes "TCC has encountered a problem". I don't get it. My
> >> handler should be first in the chain and no one else should be aware of
> >> the CTRL_CLOSE_EVENT until it returns FALSE. Rex, do you know what's
> >> going on.
> >---End Quote---
> >I'd need the source to debug it.
>
> Here are the relevant parts. Do you want more? FWIW, I'm using a custom
> entry-point and **no** C-runtime stuff (even so, I can built it
> complaint-free
> with VC8).

But how are you calling and subsequently restoring the console control
handler?

Rex Conn
JP Software

 

[vefatica]

On Sun, 03 Aug 2008 14:39:24 -0500, rconn <> wrote:

>But how are you calling and subsequently restoring the console control
>handler?

In the plugin's main (user) function:

// disable ^C, ^BREAK, save file on others
SetConsoleCtrlHandler(CtrlHandler, TRUE);
DialogBox(hThisDll, MAKEINTRESOURCE(IDD_QBAT), NULL, BoxProc);
SetConsoleCtrlHandler(CtrlHandler, FALSE); // back to normal

Though it's not at issue, I also remove/restore the handler in a
PrePostExec(BOOL bPre) routine called before starting a thread to do
Command(<batfile>,0) (and when the thread ends). That's so my
GenerateConsoleCtrlEvent() will end the batfile and thread.
The error occurs when the whole thing is idling (i.e., not running a batfile).
In any event, I do that like this:

// enable ^C and ^BREAK during execution
SetConsoleCtrlHandler(CtrlHandler, !bPre); // signals enabled/disabled

 

[vefatica]

In a plugin, I set a console ctrl handler. On receiving a signal greater than CTRL_BREAK_ENENT (for example CTRL_CLOSE_EVENT) it saves a buffer to a file with Qprintf() and returns FALSE.

When it's running in 4NTv8, and I "X" the console, it works fine. With TCCv9, it causes "TCC has encountered a problem". I don't get it. My handler should be first in the chain and no one else should be aware of the CTRL_CLOSE_EVENT until it returns FALSE. Rex, do you know what's going on.

Rex, did you repro this? I uploaded to vBulletin a bare-bones project which exhibits the same behavior ... OK in v9, bad in v9 (built with both VC7 and VC8). You should only need to adjust paths to TakeCmd.h and .lib.

 

[vefatica]

In a plugin, I set a console ctrl handler. On receiving a signal greater than CTRL_BREAK_ENENT (for example CTRL_CLOSE_EVENT) it saves a buffer to a file with Qprintf() and returns FALSE.

When it's running in 4NTv8, and I "X" the console, it works fine. With TCCv9, it causes "TCC has encountered a problem". I don't get it. My handler should be first in the chain and no one else should be aware of the CTRL_CLOSE_EVENT until it returns FALSE. Rex, do you know what's going on.

Rex, did you investigate this ... any findings? It's no big deal; I'm just curious. FWIW, I notice that using UnicodeToASCII() in that handler (as opposed to WideCharToMultiByte()) causes no problems.

 

[rconn]

vefatica wrote:

>
> Quote:
> Originally Posted by *vefatica* View Post <showthread.php?p=1645#post1645>
> In a plugin, I set a console ctrl handler. On receiving a signal greater
> than CTRL_BREAK_ENENT (for example CTRL_CLOSE_EVENT) it saves a buffer
> to a file with Qprintf() and returns FALSE.
>
> When it's running in 4NTv8, and I "X" the console, it works fine. With
> TCCv9, it causes "TCC has encountered a problem". I don't get it. My
> handler should be first in the chain and no one else should be aware of
> the CTRL_CLOSE_EVENT until it returns FALSE. Rex, do you know what's
> going on.
>
>
> Rex, did you investigate this ... any findings? It's no big deal; I'm
> just curious. FWIW, I notice that using UnicodeToASCII() in that handler
> (as opposed to WideCharToMultiByte()) causes no problems.

I'm out of town this week and won't be able to try to reproduce this for
another couple of days.

Rex Conn
JP Software