Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!ux1.cso.uiuc.edu!pequod.cso.uiuc.edu!dorner
From: dorner@pequod.cso.uiuc.edu (Steve Dorner)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Check DialogPtr returned by GetNewDialog?
Message-ID: <1991Apr3.135250.20039@ux1.cso.uiuc.edu>
Date: 3 Apr 91 13:52:50 GMT
References: <1991Apr1.224254.5399@neon.Stanford.EDU> <1991Apr2.142214.980@ux1.cso.uiuc.edu> <8690@ucdavis.ucdavis.edu>
Sender: usenet@ux1.cso.uiuc.edu (News)
Organization: University of Illinois at U-C
Lines: 20

>Well, each person has their own limit I guess.  Not having a dialog is so
>bad of an error to me that I wouldn't see any point in continuing.

There's a difference between 'not continuing' as in 'oops, I got a bad
dialog pointer, I think I'll ExitToShell' and 'not continuing' as in
'la de da, I'll just start filling up this trash dialog pointer with
stuff, and bring the mac crashing down around my ears'.

The latter approach would be more acceptable if the mac had memory
protection (Take THAT, Trigger!).  As is, it would be nice to avoid
manipulating invalid dialogs, if one could tell the things were invalid.

>functionality test should pick up an obvious error like this before the
>software even gets close to the door.

How I can test my application so that it never is on an AppleShare
volume that evaporates?
--
Steve Dorner, U of Illinois Computing Services Office
Internet: s-dorner@uiuc.edu  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner