How To Programmatically Emulate CTRL-C/CTRL-Break Keypresses?

[Jerry Fielden]

[This message has been edited by Jerry Fielden (edited December 05, 2003).]

[Clay Clear]

I doubt it. The only WinAPI that *I* can think of is TerminateProcess().
But even MS warns to only use it in extreme cases. The only one I know of that
*might* work on a DOS program. But, it's not a big deal, really.
I just wanted to move to a GUI for a "prettier" status display. The
current PB/CC app is fully functional, and does allow directly using the
CTRL-C keys to terminate the DOS app. Although I also wanted to learn the technique,
for possible future programming needs.




------------------

[Mel Bishop]

Maybe we should switch to the CC forum, but....

...I cannot do what I wanted...

Well'l'l'l'l.......Maybe, maybe not. I seem to recall that
there is a "kill app" in the winapi somewhere. Maybe that would
do?


------------------

[Clay Clear]

Mel,

I haven't gotten as far as testing it on the production apps. All the
testing I've done has been with PB/DOS programs in which I try to get the
test programs to shut themselves down. But, your last message told me that
my desired goal cannot be accomplished, since it was to use a GUI app and have
the DOS program run completely hidden so the dialog is upfront. However,
my test programs did not work either, and they always were the foreground
windows (I tested each version both in windowed mode and in a fullscreen
DOS prompt). But, you are quite correct, I cannot do what I wanted
to. No biggy, as I still have the PB/CC version of the main program. And, since
it lets the DOS program use its console window for its output/input, I can
directly press the keys and have them work.

Thank you for trying to help.


------------------

[Mel Bishop]

I re-read your original post and this is how I see it: You are
shelling from a CC program to run a DOS program and you want
the DOS program to terminate upon receipt of a Ctrl-C.

If the DOS program has the focus, then it should be possible
via stuffing the keyboard buffer. If it doesn't have the focus,
then what-ever is in the keyboard buffer will go to whatever
program that does have the focus or get sent off to laa-laa
land (one or the other).

Are you absolutely sure the DOS program has the focus and is
not rattling around in the background somewhere?


------------------

[Clay Clear]

OK, did not work. I am becoming more and more convinced that the
CTRL-C/Break is only acted upon when it is initiated at the keyboard.
Any other ideas, anybody?


------------------

[Clay Clear]

Mel,

Thanks! I just saw your edited message. I'll go try that DOS service right
now.


------------------

[Clay Clear]

Mel,

Thanks, but I need for the DOS app that was not written by ME to respond
to a simulated CTRL-C.

BTW, the GUI app would shell to a PB/DOS app that I write to generate the
CTRL-C. The GUI app (which is what it originally was, but I then ported
it to PB/CC, so I could use CTRL-C) would be dual-threaded, with the main
processing in the 2nd thread, and the dialog mechanisms in the main one.
It would be the dialog thread that would "hear" the request for CTRL-C
and then SHELL to my DOS app.


------------------

[Mel Bishop]

Have you tried Int16h? Subfunction 01 checks the keyboard
buffer, returns the character (but the character remains in
the buffer), then moves on. Subfunction 00 does the same thing,
but removes the character from the buffer. It will hang if
there are not character(s) in the buffer.

added: Subfunction 05 will simulate a keypress.
------------------


[This message has been edited by Mel Bishop (edited December 05, 2003).]

[Clay Clear]

Is this even possible? The more I have experimented, the more it
SEEMS that DOS reading those keypresses is done at the hardware level only,
meaning that they cannot be simulated by software.

I have tried stuffing the keyboard with the routine from QPP with
CHR$(3), I have tried setting bit 7 at adx 0040:???? (don't remember
the offset), I have tried invoking INT 1bh. None of these have programmatically
caused the test EXE to terminate. And, yes, I have ensured that
$OPTION CNTLBREAK ON is in the INC file. Also, after trying those
3 methods, I did an S$ = INKEY$ to force one of the DOS services
that checks for CNTRL-C (unless the PB/DOS function does not use such
a service).

The reason I want to do this is because I currently have a PB/CC app
that SHELL's to a DOS app (the DOS app was not written by me). With this
setup, I can directly press the CNTRL-C, and the DOS app appropriately
aborts. However, I wish to port the PB/CC app over to a GUI app with
PB/Win. Therefore, the GUI app would have to explicitly handle
the CNTRL-C for the DOS app, as the DOS app would be run "silently", meaning that
it would not respond to keypresses. I want to do it this way so I can keep
the GUI dialog in the forefront, to be used to show the status
of the progress through all the files that it processes.

Any ideas, anybody?


------------------