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.