On Tue, Jan 27, 2009 at 11:35 PM, Jerry Krinock <je...@ieee.org> wrote: > 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.
Yes, if you need to make a call that doesn't return until the user makes a choice, then you cannot use a sheet. Choose one or the other, but not both. However this is the sort of thing I meant when I said that this problem could indicate a design problem. Basically, I don't think that user interaction should be happening this far down in your code. When an error occurs deep down in your code, you immediately prompt the user and then make a choice there. It would be much better (in my opinion and only seeing your outline code here, not really knowing what's going on, grain of salt, offer void in Tennessee, etc.) to simply have that inner code return an error and not try to recover at all. This error can then propagate up to a more reasonable level. At that point you can then display a sheet and subsequently retry the connection or do whatever else it is that's appropriate for you. This still requires breaking your code up, but instead of "before" and "after" parts, you have a more logical, sensible division that's easier to work with. Mike _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
