Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!gatech!usenet.ins.cwru.edu!ncoast!davewt From: davewt@NCoast.ORG (David Wright) Newsgroups: comp.sys.amiga.programmer Subject: Re: Dumb windows from SAS/C programs on Workbench Message-ID: <1991May20.020743.14630@NCoast.ORG> Date: 20 May 91 02:07:43 GMT References: <1991May17.022136.1539@NCoast.ORG> Organization: North Coast Public Access Un*x (ncoast) Lines: 54 In article chopps@ro-chp.UUCP (Chris Hopps) writes: >Ah but then what about being able to handle ansi code from workbench(ie. >people to lazy to add WB Message handler...) under 1.3 some of this stuff >would crash the system if there were no STDIN/OUT. Under 2.0 there is a nice The only problem with this is that the window that SAS/C opens is very small, and most certainly not large enough to display and "real" text, maybe only 2 or 3 very short lines. Basically, it's useless. It would have been better for them to write up a function that would "throw away" the output without a system crash than open a window that people can't change easily. >icon that will bring up a cli line and then open a console so that these very >same programs can be run under 2.0. But under 1.3 the window was needed, I Actually, under 2.0 you have to ASK for that command line window by explicitly running the program as if it were from the CLI, which is NOT the same as running from the WorkBench. So this is not "fixed" even now, which is good, since there is nothing to be "fixed" at all. The operating system works the way it should. >someone who goes out of there way to handle WB messages, and handle IO >correctly, won't mind prepending an underscore to there main() to >disable such a "feature". Actually, that is NOT the best way to do it. When you declare "_main" you will be giving up most of the SAS/C startup/shutdown features that make it worthwhile to link with "c.o", "cres.o", etc. in the first place. What is porbably better is to do what several people suggested to me and copy "umain.c" from the "source" directory on one of the disks, rename it to "main.c", and remove the CTRL-C handler and window opening code. Then just put this as the first module after the startup module (c.o, cres.o, etc), and the "normal" _main will not be called in from "lc.lib". Works just great for me, does exactly what I want. >onbreak() will setup an interupt handling function for you. then when you call >chkabort(), it will check then (and only then) to see if a CTRL-(C|D) has been >pressed, if so it calls the interupt function. Now if you return a value that >is not zero from this function SAS/C will exit, otherwise it continues from >that point. so if you do not want SAS/C to exit just set some global (eek) >var. to indicate that a CTRL-(C|D), from your interupt function, then >return(0); then have the regular program check the state of the global, if it >is true, call your own exit routine, or whatever.... This is the ANSI way to do it basically, but in probably most "event" oriented systems is NOT the best way to do it. I want to have it do various things depending on what part of the program it is in when the signal arrives. Using functions like "onbreak()" pretty much assume you want to do the same thing every time the event occurs, which is basically a holdover from line-oriented Unix applications which (for instance) assume that a certain signal means to terminate (kill) the program. On the Amiga what appears to be the best method (to me at least) is to set one of the signals "bits" for the type of break you want to receive, and just OR them with the other bits you feed to "Wait()". This will work for MOST applications, but others, such as mine, which have many loops during which an abort would NOT be handled the same as in other loops, or even normal program flow, work better using the "SetSignal()" function, which is basically what I do, since I want to throw away any signals that occur when I am not in a part of the program that can handle them. Dave