On Dec 16, 2008, at 6:10 AM, Philip Aker wrote: On 2008-12-15, at 17:47:42, 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.
If a script ignores replies:
ignoring application responses tell application "Finder" to display alert "Hi!" end ignoring
the ‘display alert’ event is sent with send mode kAENoReply, and AESend() returns immediately after sending the event. When Finder replies, the reply is ignored by the application running the script. tell application "Target" -- dd#1 set field "UnixUserName" of form 1 to text returned of (display dialog "AppleScript Team member name:" default answer "chris") end tell my AutoCompleteUserFields() -- targets another app and gets some input values on idle tell application "Target" -- dd#2 set psize to text returned of (display dialog "Page size:" default answer "8.5x11") end tell my AutoCompletePageFormat(psize) my ProcessPrintJobFolderFromCurrentForm() end try Now the script is running and paused at dd#1 but Interloper has a script aimed at Target which it sends on startup. Guess what? It's being run from a cron job and activates while the user is typing into dd#1 with the intent to fill out field "UnixUserName".
Note that if you run that script today, between dd#1 and dd#2 the user can interact with Target, and your cron job can send Apple Events to Target. That is the case today and will always be the case no matter what we do with ‘display alert’ and ‘display dialog’.
Between any two Apple Events, an application may receive user input or Apple Events from other scripts or applications.
All I'm talking about is preventing the user from clicking in Target while the script is waiting for the user to enter the name for dd#1 (and then again later, while waiting for the user to enter the page size for dd#2).
-- Chris Page
The other, other AppleScript Chris
|