johnsone@uxh.cso.uiuc.edu (Erik A. Johnson) (04/01/91)
Do any of you check to see if the DialogPtr that GetNewDialog returns is
valid in any way? Is there any way to determine that GetNewDialog had no
problems (i.e. it found the necessary resources and got the necessary
memory allocated)? IM-I-413 says "If either the dialog template resource
or the item list resource can't be read, the function result is undefined."
I tried:
DialogPtr aDialogPtr;
...
aDialogPtr = 0L;
aDialogPtr = GetNewDialog( ... );
if (aDialogPtr == 0L)
{ /* got some sort of error */
}
else
{ /* do the dialog stuff */
}
This seems to work, but given the above quote from IM, I'm hesitant to count
on it working. Any suggestions? E-mail and I'll summarize. Thanks.
Erik A. Johnson, Graduate Student \ Internet: johnsone@uxh.cso.uiuc.edu
Aeronautical & Astronautical Engineering \
University of Illinois at Urbana-Champaign \ AmericaOnline: ErikAJbin@primate.wisc.edu (Brain in Neutral) (04/02/91)
From article <1991Apr1.052536.27902@ux1.cso.uiuc.edu>, by johnsone@uxh.cso.uiuc.edu (Erik A. Johnson): > Do any of you check to see if the DialogPtr that GetNewDialog returns is > valid in any way? Is there any way to determine that GetNewDialog had no > problems (i.e. it found the necessary resources and got the necessary > memory allocated)? You want to read Technical Note 4 and then hold your breath in awe at the advice it gives: Assume there is no error -- Paul DuBois I don't see anything about "separation" dubois@primate.wisc.edu in the Constitution. Do you?
kaufman@neon.Stanford.EDU (Marc T. Kaufman) (04/02/91)
In article <4143@uakari.primate.wisc.edu> bin@primate.wisc.edu writes: >From article <1991Apr1.052536.27902@ux1.cso.uiuc.edu>, by johnsone@uxh.cso.uiuc.edu (Erik A. Johnson): -> Do any of you check to see if the DialogPtr that GetNewDialog returns is -> valid in any way? Is there any way to determine that GetNewDialog had no -> problems (i.e. it found the necessary resources and got the necessary -> memory allocated)? >You want to read Technical Note 4 and then hold your breath in awe >at the advice it gives: > Assume there is no error So what do you want do if there IS an error... put up an ALERT dialog? [Use the sound manager to SAY the alert. Use the CLUT to flash morse code messages on the screen. Initiate a shutdown. Send Email. Draw directly to the desktop] Marc Kaufman (kaufman@Neon.stanford.edu)
dorner@pequod.cso.uiuc.edu (Steve Dorner) (04/02/91)
>-> Do any of you check to see if the DialogPtr that GetNewDialog returns is >-> valid in any way? >>You want to read Technical Note 4 and then hold your breath in awe >>at the advice it gives: >> Assume there is no error >So what do you want do if there IS an error... put up an ALERT dialog? There are any number of reasonable things you could do, if you knew that GetNewDialog had failed: 1. Skip the alert, and hope for the best. 2. Pitch some clean windows, and then try an alert. 3. Put up a 'vital resource not found' alert (which might work). 4. Quietly ExitToShell. Any of these alternatives smell better than trying to put up an a nonexistent dialog. I agree with Apple in principle; there's a point at which things are SO BAD that I don't care what happens anymore. I'm not sure I would have pegged GetNewDialog as such a place, though. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
cs483106@umbc5.umbc.edu (cs483106) (04/03/91)
In article <1991Apr2.142214.980@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: |>-> Do any of you check to see if the DialogPtr that GetNewDialog returns is |>-> valid in any way? |>>You want to read Technical Note 4 and then hold your breath in awe |>>at the advice it gives: |>> Assume there is no error |>So what do you want do if there IS an error... put up an ALERT dialog? |There are any number of reasonable things you could do, if you knew that |GetNewDialog had failed: | |1. Skip the alert, and hope for the best. |2. Pitch some clean windows, and then try an alert. |3. Put up a 'vital resource not found' alert (which might work). |4. Quietly ExitToShell. | |Any of these alternatives smell better than trying to put up an a nonexistent |dialog. | |I agree with Apple in principle; there's a point at which things are SO BAD |that I don't care what happens anymore. I'm not sure I would have pegged |GetNewDialog as such a place, though. | |Steve Dorner, U of Illinois Computing Services Office |Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner The most interesting part about this discussion(at least in my opinion) is that on older macs(pretty much everything before the IIsi and LC), you could often get away with doing things such as a HideDialog on a bogus dialog pointer(such as one you got from a GetNewDialog on a non-existant resource). In the older machines, HideDialog would simply ignore it. On the IIsi, HideDialog bombs in this situation. VERY interesting. "Pope" Q.E.D Michael Kohne mikek@isis.ngs.noaa.gov
johnsone@uxh.cso.uiuc.edu (Erik A. Johnson) (04/03/91)
dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >>-> Do any of you check to see if the DialogPtr that GetNewDialog returns is >>-> valid in any way? >>>You want to read Technical Note 4 and then hold your breath in awe >>>at the advice it gives: >>> Assume there is no error >>So what do you want do if there IS an error... put up an ALERT dialog? > >There are any number of reasonable things you could do, if you knew that >GetNewDialog had failed: > >1. Skip the alert, and hope for the best. >2. Pitch some clean windows, and then try an alert. >3. Put up a 'vital resource not found' alert (which might work). >4. Quietly ExitToShell. > >Any of these alternatives smell better than trying to put up an a nonexistent >dialog. This is exactly what I was trying to get at in my original question about checking the validity of a GetNewDialog DialogPtr. In a program I'm writing, I was going to check for an error and then SysBeep() at the user a time or two and then simply ExitToShell(), rather than forge on ahead and (probably) cause the whole system to crash. By the way, thanks for pointing out TechNote 4. (Duh, look, Erik! :-) But the question still stands. How can I test for GetNewDialog's validity? Erik A. Johnson, Graduate Student \ Internet: johnsone@uxh.cso.uiuc.edu Aeronautical & Astronautical Engineering \ University of Illinois at Urbana-Champaign \ AmericaOnline: ErikAJ
lim@iris.ucdavis.edu (Lloyd Lim) (04/03/91)
In article <1991Apr2.142214.980@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >I agree with Apple in principle; there's a point at which things are SO BAD >that I don't care what happens anymore. I'm not sure I would have pegged >GetNewDialog as such a place, though. 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. Any quick functionality test should pick up an obvious error like this before the software even gets close to the door. The only reason I could see this happening in a released app is if someone fiddling with ResEdit deleted some resources. That shouldn't be the programmer's fault. This reminds of the discussion a while back on how to prevent LoadSeg from crashing if a code resource is missing. +++ Lloyd Lim Internet: lim@iris.eecs.ucdavis.edu America Online: LimUnltd Compuserve: 72647,660 US Mail: 215 Lysle Leach Hall, U.C. Davis, Davis, CA 95616
dorner@pequod.cso.uiuc.edu (Steve Dorner) (04/03/91)
>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
mxmora@unix.SRI.COM (Matt Mora) (04/04/91)
In article <8690@ucdavis.ucdavis.edu> lim@iris.ucdavis.edu (Lloyd Lim) writes: >In article <1991Apr2.142214.980@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >>I agree with Apple in principle; there's a point at which things are SO BAD >>that I don't care what happens anymore. I'm not sure I would have pegged >>GetNewDialog as such a place, though. [stuff deleted] >The only reason I could see this happening in a released app is if someone >fiddling with ResEdit deleted some resources. That shouldn't be the >programmer's fault. This reminds of the discussion a while back on how to >prevent LoadSeg from crashing if a code resource is missing. What do think is better, putting up a window with an error message saying "This application is damaged please reinstall it" or the Bomb Dialog box. Its true its not the programmers fault that the user trashed the resources somehow but at least its the programmers job to try to exit gracefully. But of course all this error checking can become a pain in the butt and make your code more complex than need be. I think ( carefull Apple bashing is comming) Apple should have done a better job at reporting errors from the traps. By the way how does MacApp handle this situation? -- ___________________________________________________________ Matthew Mora | my Mac Matt_Mora@sri.com SRI International | my unix mxmora@unix.sri.com ___________________________________________________________
Jim.Spencer@p510.f22.n282.z1.fidonet.org (Jim Spencer) (04/04/91)
Marc T. Kaufman writes in a message to All MTK> So what do you want do if there IS an error... put up an ALERT MTK> dialog? [Use the sound manager to SAY the alert. Use the CLUT MTK> to flash morse code messages on the screen. Initiate a shutdown. MTK> Send Email. Draw directly to the desktop] Doesn't it depend on what the error is? Maybe the resource wasn't found; maybe you had enough foresight to provide some emergency memory reserve to permit you to put up an error message; etc. etc.
Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) (04/08/91)
Matt Mora writes in a message to All
MM> By the way how does MacApp handle this situation?
MacApp doesn't use the Dialog Mangler.
Lawson
--
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English
Internet: Lawson.English@p88.f15.n300.z1.fidonet.org