Re: NSAlert and threading

[Jens Alfke]

> On May 23, 2016, at 2:41 PM, Fritz Anderson  wrote:
> 
> Hence the rule that you don’t do _anything_ lengthy on the main (GUI-runloop) 
> thread. You can see how using a separate thread would solve your problem. 
> Welcome to 2003. 

Less dogmatically, you can use -performSelector:withObject:afterDelay:, with a 
zero delay, to schedule the actual work to take place right after the alert 
finishes handling the event and closing.

—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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSAlert and threading

[Fritz Anderson]

On 23 May 2016, at 4:14 PM, Tom Doan  wrote:
> 
> I have an menu operation which, before it fully executes, pops up 
> an NSAlert asking a Yes/No question ("Selection Only(Y/N)?") then, 
> depending upon the answer will either apply to the whole list or just 
> the selection. However, no matter what I do (other than putting the 
> operation in a separate thread), the alert box stays on the screen 
> until the operation is done. release doesn't work. orderout on the 
> window doesn't work. Is there any way to do this (other than 
> changing the threading) so the alert box goes away when I'm done 
> with it?

Do I understand correctly that you perform this lengthy operation in direct 
response to the button click in the alert? If so, this is the expected behavior.

{ F : F ∈ any modern framework } works from a run loop. At each pass in the 
loop, the framework looks for the next event to handle (e.g. a click, or the 
need to close a window). After interpreting it (for instance as a button 
click), it calls the appropriate handler, sometimes in your code (such as the 
callback for the alert buttons), sometimes other parts of the framework (such 
as the part that removes a window from the display list).

If your handler immediately executes a lengthy operation without returning to 
the runloop, then the “close the alert” event won’t come up until the lengthy 
operation concludes and your handler returns control to the runloop. Then the 
loop finds the close-alert event, and takes care of it.

Hence the rule that you don’t do _anything_ lengthy on the main (GUI-runloop) 
thread. You can see how using a separate thread would solve your problem. 
Welcome to 2003. 

Apple has gone to great lengths to make threading easy (from the sound of it, 
your case isn’t all that bad), but it can’t hide it from you entirely.

— F


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSAlert and threading

[Tom Doan]

I have an menu operation which, before it fully executes, pops up 
an NSAlert asking a Yes/No question ("Selection Only(Y/N)?") then, 
depending upon the answer will either apply to the whole list or just 
the selection. However, no matter what I do (other than putting the 
operation in a separate thread), the alert box stays on the screen 
until the operation is done. release doesn't work. orderout on the 
window doesn't work. Is there any way to do this (other than 
changing the threading) so the alert box goes away when I'm done 
with it?

Best regards,

Tom Doan
Estima
---
1560 Sherman Ave #1029
Evanston, IL 60201
USA


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com