GetLine and break handlers

[p.f.moore]

If I leave the break handling unchanged, and call GetLine to read a
line from the console in my plugin, then when I hit Ctrl-C while the
plugin is waiting for input, the whole TCC instance exits. If I
disable Ctrl-C handling, I can't quit the input without entering
something (and the TCC instance exits when signals are re-enabled).

So presumably I need to install my own break handler around GetLine?
And I guess I need to do something like longjmp to regain control
after Ctrl-C is pressed? That's doable, but pretty messy. Have I
missed a simpler approach?

Thanks,
Paul.

 

[vefatica]

On Tue, 22 Jul 2008 09:13:02 -0500, "p.f.moore" <> wrote:

>If I leave the break handling unchanged, and call GetLine to read a
>line from the console in my plugin, then when I hit Ctrl-C while the
>plugin is waiting for input, the whole TCC instance exits.

My guess is that that shouldn't happen. Perhaps Rex will have a look at it.

 

[vefatica]

On Tue, 22 Jul 2008 15:08:29 -0500, vefatica <> wrote:

>---Quote---
>>If I leave the break handling unchanged, and call GetLine to read a
>>line from the console in my plugin, then when I hit Ctrl-C while the
>>plugin is waiting for input, the whole TCC instance exits.
>---End Quote---
>My guess is that that shouldn't happen. Perhaps Rex will have a look at it.

The SDK's egets() behaves the same way, causing TCC to disappear when called by
a plugin and interrupted with <Ctrl-C>.

egets() seems a nice alternative to GetLine() for console input since it allows
the user to edit the line.

 

[p.f.moore]

On 22/07/2008, vefatica <> wrote:

> On Tue, 22 Jul 2008 15:08:29 -0500, vefatica <> wrote:
> >>If I leave the break handling unchanged, and call GetLine to read a
> >>line from the console in my plugin, then when I hit Ctrl-C while the
> >>plugin is waiting for input, the whole TCC instance exits.

> >My guess is that that shouldn't happen. Perhaps Rex will have a look at it.

> The SDK's egets() behaves the same way, causing TCC to disappear when
> called by a plugin and interrupted with <Ctrl-C>.
>
> egets() seems a nice alternative to GetLine() for console input since it allows
> the user to edit the line.

Both GetLine and egets seem to have the following properties:

- Ctrl-C causes TCC to terminate
- If you use a user-defined break handler, you cannot get
GetLine/egets to return (they are probably looping until they get a
return character)

Between them, these 2 properties leave only the option of completely
disabling signals, which is safe but hardly friendly :-(

Paul.

 

[p.f.moore]

On 23/07/2008, Paul Moore <[email protected]> wrote:

> Between them, these 2 properties leave only the option of completely
> disabling signals, which is safe but hardly friendly :-(

Actually, it's worse than that in one way, but better in another.
Break handling in plugins seems utterly broken. Any break signal while
a plugin is active seems to terminate TCC. See the attached trivial
plugin, which just runs Cmd_Delay. If you hit Ctrl-C while the delay
is ongoing, TCC exits.

This looks like a bug in TCC (I'm using 9.02.151) as it works fine in 4NT 8.

Paul.

// PlugIn.cpp - demonstration plugin for 4NT / TC 7.0

#define UNICODE 1
#define _UNICODE 1

#include <windows.h>

#include "PlugIn.h"
#include "TakeCmd.h"


BOOL APIENTRY DllMain( HANDLE hModule, DWORD dwReason, LPVOID lpReserved )
{
switch( dwReason ) {
case DLL_PROCESS_ATTACH:
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}


DLLExports LPPLUGININFO WINAPI GetPluginInfo( void )
{
static PLUGININFO piInfo;

piInfo.pszDll = (LPTSTR)L"TestBreak";
piInfo.pszAuthor = (LPTSTR)L"Paul Moore";
piInfo.pszEmail = (LPTSTR)L"[email protected]";
piInfo.pszWWW = (LPTSTR)L"example.com";
piInfo.pszDescription = (LPTSTR)L"Test plugin";
piInfo.pszFunctions = (LPTSTR)L"test";
piInfo.nMajor = 1;
piInfo.nMinor = 0;
piInfo.nBuild = 1;

return &piInfo;
}


DLLExports BOOL WINAPI InitializePlugin( void )
{
return 0;
}


DLLExports BOOL WINAPI ShutdownPlugin( BOOL bEndProcess )
{
return 0;
}

DLLExports INT WINAPI test (LPTSTR lpszString)
{
Delay_Cmd(L"12");
return 0;
}

 

[p.f.moore]

On 23/07/2008, Paul Moore <[email protected]> wrote:

> Between them, these 2 properties leave only the option of completely
> disabling signals, which is safe but hardly friendly :-(

Actually, it's worse than that in one way, but better in another.
Break handling in plugins seems utterly broken. Any break signal while
a plugin is active seems to terminate TCC. See the attached trivial
plugin, which just runs Cmd_Delay. If you hit Ctrl-C while the delay
is ongoing, TCC exits.

This looks like a bug in TCC (I'm using 9.02.151) as it works fine in 4NT 8.

Paul.

// PlugIn.cpp - demonstration plugin for 4NT / TC 7.0

#define UNICODE 1
#define _UNICODE 1

#include <windows.h>

#include "PlugIn.h"
#include "TakeCmd.h"


BOOL APIENTRY DllMain( HANDLE hModule, DWORD dwReason, LPVOID lpReserved )
{
switch( dwReason ) {
case DLL_PROCESS_ATTACH:
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}


DLLExports LPPLUGININFO WINAPI GetPluginInfo( void )
{
static PLUGININFO piInfo;

piInfo.pszDll = (LPTSTR)L"TestBreak";
piInfo.pszAuthor = (LPTSTR)L"Paul Moore";
piInfo.pszEmail = (LPTSTR)L"[email protected]";
piInfo.pszWWW = (LPTSTR)L"example.com";
piInfo.pszDescription = (LPTSTR)L"Test plugin";
piInfo.pszFunctions = (LPTSTR)L"test";
piInfo.nMajor = 1;
piInfo.nMinor = 0;
piInfo.nBuild = 1;

return &piInfo;
}


DLLExports BOOL WINAPI InitializePlugin( void )
{
return 0;
}


DLLExports BOOL WINAPI ShutdownPlugin( BOOL bEndProcess )
{
return 0;
}

DLLExports INT WINAPI test (LPTSTR lpszString)
{
Delay_Cmd(L"12");
return 0;
}

 

[vefatica]

On Wed, 23 Jul 2008 08:06:40 -0500, "p.f.moore" <> wrote:

>---Quote---
>> Between them, these 2 properties leave only the option of completely
>> disabling signals, which is safe but hardly friendly :-(
>---End Quote---
>Actually, it's worse than that in one way, but better in another.
>Break handling in plugins seems utterly broken. Any break signal while
>a plugin is active seems to terminate TCC. See the attached trivial
>plugin, which just runs Cmd_Delay. If you hit Ctrl-C while the delay
>is ongoing, TCC exits.
>
>This looks like a bug in TCC (I'm using 9.02.151) as it works fine in 4NT 8.

All that seems to be true. Things work well in v8 and semingly poorly in v9.

It should be noted that a console control handler set by a plugin works fine if
it returns TRUE. I use one to be able to interrupt my KEYTIMES or GREPP. But
returning TRUE, they won't let the user interrupt anything at a higher level (a
batch file for example).

 

[vefatica]

p.f.moore:

Both GetLine and egets seem to have the following properties:

- Ctrl-C causes TCC to terminate
- If you use a user-defined break handler, you cannot get
GetLine/egets to return (they are probably looping until they get a
return character)

This doesn't help with interrupting GetLine() or egets() in v9, but I learned an interestin technique (kludge). In my KEYTIMES, which can go on for quite a while, I installed a control handler which sets the global bInterrupt to TRUE and returns TRUE (not invoking further ctrl handlers). Upon finding bInterrupt to be TRUE, my recursive registry-delving function halts and cleans up its mess (closes handles, et c.). Then just before KEYTIMES returns, if it had been interrupted, I recreate the signal with GenerateConsoleCtrlEvent(). This seems to work around the problem with passing the event on to TCC earlier (which causes v9 to go away).

Rex, is there a more elegant way to let a plugin function clean up on getting a signal and then pass the signal to a higher authority? Do you have any try/catch handlers that I can throw to? And is there a way a plugin can interrupt GetLine() or egets()? Can I put them in a "try" block and use a ctrl handler to throw an exception?