[Coco] OS9 Programming question

[Bill Pierce]

Mr Gault,
First, the program is my Sound Chaser program. The forked programs are the players. 
If I didn't use the intercept, the <break> key would just terminate the players leaving midi notes hanging without sending a midi noteoff to the midi device which is an external device. The notes will then just play until the external midi device is reset. The intercept has to be there to direct the program to turn all notes off before exiting.
The overlay windows are created by the players and also removed on exit (either on end or break terminated).
Also, the calling program sets the "wait(0)" state after the fork to suspend operation until the forked program is terminated.
I'm beginning to think the problem is that the players being intercepted are returning ERROR #2 since the break key was pressed (according to the manual). Either that or the signal is being returned as well, but if it's a signal, it should be caught by the initial program's intercept. 
Also, in one of the player intercepts, there was a function that would print a warning if there is a "odd" signal (not 2 or 3). It was printing signal 4. According to the manual, signal 4 is S$Window - Window change. At this point, the process is still running and the overlay window is open. 

I never noticed this when playing individual songs. Now I have a selection routine that allows the user to select a list of songs and play them in order of selection. After playing a list of 20 songs, you get  20 screen "blips" when they're done. It's odd that it waits till all the songs are over and returns to the menu loop as the loop returns to the main program before calling the next player. Then it seems accept the errors/signals as keystrokes on the keyin loop. This is where the "blip" is occuring. I may need a way to clear the input buffer. fflush(STDIN/STDOUT/STDERR) does nothing (I tried all three). Which this would just throw them all out at one time anyway.

The calling routine looks something like:

for(sngnum = 0; sngnum <= numsng; sngnum++) {
    fname = selection[sngnum];
    args = parms[sngnum];
    os9fork(fname,len,args,1,1,80);
    wait(0);
}

any ideas?
Bill P

Music from the Tandy/Radio Shack Color Computer 2 & 3
https://sites.google.com/site/dabarnstudio/
Bill Pierce
ooogalapasooo at aol.com




-----Original Message-----
From: Robert Gault <robert.gault at att.net>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Fri, Jan 18, 2013 12:16 pm
Subject: Re: [Coco] OS9 Programming question


Bill Pierce wrote:
>
> Hi guys,
> I have an OS9 program that runs a loop that forks several other programs in 
succession in overlay windows. Each program sets an intercept that catches the 
break key and terminates on break and goes to the next program until the loop is 
finished. When the loop exits and returns to the main window, all the "break" 
keys that were pressed in the other programs all echo to the main window. The 
screen redraws for each break key that was pressed for each of the programs that 
was run.
> Is there some way to clear those signals so they don't come back to the main 
program? The main program has it's own intercept which is reset on return, but 
it doesn't seem to do any good in this case. If I don't "break" the other 
programs and let them finish, the program runs fine on return.
> All the program are written in C and Asm.
>
> Any suggestions?
> Bill P
>

The OS-9 manual says an intercept routine prevents a process from terminating on 

a signal but you say you want the process to be killed. Do you also want the 
overlay windows to be removed? What happens if the forked programs do not have 
intercept routines?


--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco