Xref: utzoo comp.sys.mac:39258 comp.sys.mac.programmer:9390 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!psuvax1!gatech!prism!vsserv!loligo!pepke From: pepke@loligo (Eric Pepke) Newsgroups: comp.sys.mac,comp.sys.mac.programmer Subject: Re: Macintosh One-Liners Message-ID: <229@vsserv.scri.fsu.edu> Date: 29 Sep 89 20:12:42 GMT References: <221@vsserv.scri.fsu.edu> <4466@internal.Apple.COM> Sender: news@vsserv.scri.fsu.edu Reply-To: pepke@loligo.UUCP (Eric Pepke) Distribution: na Organization: Supercomputer Computations Research Institute Lines: 49 In article <4466@internal.Apple.COM> rmh@apple.com (Rick Holzgrafe) writes: >This idea is great, and I like the sample list. I've already printed it >down to post outside my cube wall. (Yes, at Apple! :-) Aw, gee. >I have one suggested correction. Instead of: >> Ensure that the current grafPort is valid at ALL times. DA's might >> change it. >how about simply: > Always call SetPort before drawing. >Just a suggestion, no need for further discussion. I want to. This is to avoid a much more insidious problem, which seems ridiculously unlikely but has caused crashes that have been mentioned on the net. The scenario involves two buggy desk accessories whose bugs are subtle and don't show up very often: Desk accessory A plays hard and fast with its grafPorts. It doesn't bother to save the old grafPort when it puts up a window. Most applications don't care, because they always set their grafPort before drawing. Desk accessory B uses one of the QuickDraw calls which don't really affect the current grafPort but require that the current grafPort be valid. I can't remember what these calls are, but they exist. Now consider this--A opens a window and sets the port to the window. A closes the window, leaving the current grafPort in never land. B tries to do its little thing. Kapow! It doesn't even have to be a desk accessory; it can be some background task that uses a dopey pre-notification manager scheme of alerting the user. Unfortunately, in cases like this it is the application which is blamed for the crash. It is easy to avoid simply by doing a SetPort to a known good grafPort every time through the event loop. Perhaps I should say this outright. It is a subtle and rare problem, I know, but one of the major points of the programming one-liners is that if you do what they say, you simply avoid a large number of well known subtle and rare problems. Eric Pepke INTERNET: pepke@gw.scri.fsu.edu Supercomputer Computations Research Institute MFENET: pepke@fsu Florida State University SPAN: scri::pepke Tallahassee, FL 32306-4052 BITNET: pepke@fsu Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers.