On 12 May '08, at 5:18 PM, Rua Haszard Morris wrote:
Is there a way to wrap up an NSAlert, the beginSheetModalForWindow
call, and the alertDidEnd implementation, such that a caller can
just call one function which blocks until the alert is dismissed?
No, because the application continues to run and other windows are
still able to handle user input.
So if you wrote a routine like this, it would have to run the
runloop so events got handled; and then your code associated with
actions in other windows could be called re-entrantly down inside
your blocking function.
I see.. this makes sense. In my case, the alert is displayed on top of
an application-modal dialog, which makes it more feasible I suppose,
but still an inappropriate approach?
As I rearrange the code that generates and handles the first, custom
sheet (which uses runModalForWindow), to accomodate the second
(confirmation in a rare error situation), standard sheet, I'll
probably become more comfortable with this approach.
Actually, if I was to make a new alert (in the nib) myself, and show
it using runModalForWindow, would this work?
Thanks
Rua HM.
The worst case is if you put up a sheet on one window, then the user
does something in another window that puts up a sheet there too. Now
you're inside two nested wait-for-sheet-to-finish functions. ...And
then the user dismisses the first sheet. Somehow you have to return
from the outermost function without returning from the inner one! o_O
The only way to make a programming style like this work is to use a
thread per window (as the BeOS did), or coroutines, or something
else exotic.
—Jens
_______________________________________________
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 [EMAIL PROTECTED]
