• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: on AESend blocking input events (was Re: Tell Blocks Considered Harmful)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: on AESend blocking input events (was Re: Tell Blocks Considered Harmful)


  • Subject: Re: on AESend blocking input events (was Re: Tell Blocks Considered Harmful)
  • From: has <email@hidden>
  • Date: Wed, 17 Dec 2008 20:02:58 +0000

Chris Page wrote:

To be clear, when a script issues the ‘display dialog’ command, the  
script pauses until the dialog is dismissed and the command is  
completed. Similarly, the application running the script usually  
pauses, too. Most applications don't respond to user input while  
waiting on an Apple Event to reply.

The I believe the behavior is determined by the send mode options  
such as kAEQueueReply and kAEProcessNonReplyEvents.

That's not what I was referring to. I was referring to user  
interaction, e.g., mouse clicks and keyboard input. The Apple Event  
send mode only controls Apple Events, not user input events.

When an application sends an Apple Event to another process and waits  
for a reply (the usual case), while it is waiting for the reply the  
application doesn't respond to user input events, by default. They  
have to make an effort to work around a barrier presented by AESend()  
in order to do that, and most don't.

AESend dates back to the bad old pre-OS X days where you had to jump through hoops to do things concurrently. I doubt there's many situations in OS X where you really need to use it. Nowadays, if you want to avoid blocking your application's main event loop while sending Apple events, you would send your events from a background thread via AESendMessage, allocating the thread its own Mach port to receive replies on. (I've done it myself using appscript.)

The only exception would be if your application is running an AppleScript, and it's the AppleScript that's sending the events - in that case you have to do it on the main thread due to AppleScript's lack of thread safety. (Thanks for that info, btw, Chris.)

has
-- 
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users

This email sent to email@hidden

  • Prev by Date: Re: Tell Blocks Considered Harmful (was Re: open for access)
  • Next by Date: Re: on blocking target applications' GUIs (was Re: Tell Blocks Considered Harmful)
  • Previous by thread: Re: Option Key Down
  • Next by thread: Re: on blocking target applications' GUIs (was Re: Tell Blocks Considered Harmful)
  • Index(es):
    • Date
    • Thread