Frank Merrow wrote:
>
> Okay, so signals don't work ActiveState builds.
>
> Does anyone out there have a trick or spoof for catching ctrl-c?
>
> I've tried running nested eval's, double processes . . .
>
> I am racking my brain for a way to get around the limitation and make sure
> some processing is done after everything is blown away.
>
> For me, the real point is that I have some clean up that HAS TO BE DONE . .
> . I don't care about the ctrl-c per se . . . I just want to make sure my
> clean up is done even if the user blows me away.
>
> Any ideas for a work around?
1. You could remap the key altogether <g> (there's a way to do it in the
registry)
2. I don't know if you're running an interactive program, but if not,
you may
be able to do a "start" or otherwise spawn a separate process in its own
process
group (don't know if you'd avoid ctrl-c problems this way, though)
3. Along the same lines, you could perhaps write a little program loader
in C
that catches the ctrl-c and doesn't propagate it.
Both are untested, but would depend on how signals propagate through a
process group.
Have you read the Win32 API refs on CreateProcess? (I'm hoping you're
using Windows NT).
You can suppress (or at least modify) control-C behavior using various
flags.
However, control-break is still passed through. You can (I think) start
it with a new
console, which could be minimized, which might help.
Another possibility is to use Tk, which doesn't look at control-C as a
break key.
You can, in fact, bind it.
--
Ned Konz
currently: Stanwood, WA
email: [EMAIL PROTECTED]
homepage: http://bike-nomad.com, Perl homepage:
http://bike-nomad.com/perl
---
You are currently subscribed to perl-win32-users as: [archive@jab.org]
To unsubscribe, forward this message to
[EMAIL PROTECTED]
For non-automated Mailing List support, send email to
[EMAIL PROTECTED]
