Thanks for your thoughts, Graham and Michael. My irritation is not so
much with the "Do you really want to do this? How?" dialogs, but in
presenting errors.
Probably I should have given a more concrete example, as I now have
[1]. This simplified code from my real app performs a "sync in" to a
document of some data from a source on a remote server. For many good
reasons (for example, to facilitate other programmatic entries into
this process and to allow subclasses to have different
implementations), the -makeConnection method is the sixth function in
a call stack that begins with the IBAction syncIn:.
Now, what if the network connection fails? I've been presenting the
error in a modal dialog, but as I said in my original post, since this
network connection failure only affects the current document, I
believe that good UI design would want the error presented in a sheet
on the document window instead. However, to do so, my code would
become a bloody mess.
So I looked again at -[NSDocument presentError:] and saw that it "does
not return until the user dismisses the alert". Whoopee!! But upon
trying it, I see that gives a free-standing modal dialog box instead
of the sheet that I want. Oh, well.
Apple's dialog-box implementation of -[NSDocument presentError:] leads
me to believe that Apple has punted on this problem as well. I guess
I'll just continue to use the modal dialog -- until I have a free day
to consider this challenge.
Jerry
[1] Note: In real life, these methods are in several different
classes, but I mashed them together for easier reading.
