dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/26/87)
I would like to get SIGBREAKF_CTRL_[CDEF] working before I release the next DME version. Anybody know how to do it from a console.device or plain intuition window? -Matt
andy@cbmvax.UUCP (09/27/87)
In article <8709260241.AA18897@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > > I would like to get SIGBREAKF_CTRL_[CDEF] working before I release >the next DME version. Anybody know how to do it from a console.device >or plain intuition window? > > -Matt Easy enoug...in your console/intuition window, you have somewhere a place where you are doing a Wait() on multiple signals, ie a line like: WakeUpBit= Wait((1<<window->UserPort->mp_SigBit)|(1<<consoleMsgPort.mp_SigBit)); This line waits a signal from either Intuition or the console.device. Well, just add the SIGBREAKF_CTRL_C to the Wait(), ie WakeUpBit= Wait((1<<window->UserPort->mp_SigBit)|(1<<consoleMsgPort.mp_SigBit) |SIGBREAKF_CTRL_C); And that's all there is to it. andy -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore-Amiga, Inc. "Interfere? Of course we'll interfere. Always do what you're best at, I always say." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
joels@tekred.TEK.COM (Joel Swank) (09/30/87)
> > This line waits a signal from either Intuition or the console.device. > > Well, just add the SIGBREAKF_CTRL_C to the Wait(), ie > > WakeUpBit= Wait((1<<window->UserPort->mp_SigBit)|(1<<consoleMsgPort.mp_SigBit) > |SIGBREAKF_CTRL_C); > > > And that's all there is to it. > > andy > That's great if you are waiting on something. But what if you are just processing at full speed? You can to use SetSignal(0,0) to return the signal bits. If you use Manx 3.4 you have a facility that does this. Manx lower level IO routines call a routine "Chk_Abort". Chk_Abort does a SetSignal and if CTRL_C is set calls the routine "_abort". You can include your own _abort subroutine to do cleanup and an "exit(1)". If _abort returns execution continues. So you can capture CTRL_C and ignore it. The standard _abort displays '^C' and exits. If the program is not doing any IO, you will have to insert your own call to Chk_Abort at the apropriate place. It only consumes about 70 usec by my measurements. A note: If you are using Manx and have a program that does a lot of IO and try to do your own SetSignal to get control, it will very likely fail because Chk_Abort beats you to it. If you must use your own SetSignal (to check for [DEF]) stub off Chk_Abort so that your program gets all signals. There is one problem. If the CTRL_C came from the keyboard (rather than the BREAK command) there will be a character left in the input stream. A getchar() in the _abort routine will take care of this problem, but then if the CTRL_C came from BREAK _abort will hang waiting for a character. I haven't found a way to tell if a character is there without waiting if its not. Anybody know? Joel Swank Tektronix, Redmond, Oregon joels@tekred.TEK.COM