Re: Display Dialog
Re: Display Dialog
- Subject: Re: Display Dialog
- From: Stan Cleveland <email@hidden>
- Date: Fri, 17 Dec 2010 12:59:50 -0800
On Dec 17, 2010, at 11:25 AM, Luther Fuller wrote:
> It's more complicated than that, so I will suggest more ...
>
> Suppose you have two AppleScripted applications. One of them, call it "A", tells Mail to do a bunch of stuff. The other, call it "B", does just one thing, it tells Mail to display a dialog.
>
> If you run "B", but before replying to the dialog you run "A", then "A" can't operate because Mail is busy displaying the dialog.
That's because 'display dialog' is not thread-safe (that is, it doesn't "share" well), so AppleScript knows to give it full control of the Mail app and to queue up any other events that arrive in the mean time for later execution.
> And if you run "A", then "B", then, I think, there will be intereference, but I haven't verified this.
Perhaps, but only in the sense that the non-thread-safe dialog would seize control of Mail, while other events are queued.
> I ran into this while writing an archiver & organizer for Mail. There is a basic principle here ...
>
> An application should not be allowed to respond to two users at the same time.
>
> Imagine a Mac with one screen, two keyboards and two mice (mouses?) and two persons trying to use the same application. Keep imagining ... very confusing, isn't it!
>
> Unfortunately, this CAN happen when one of the users is an AppleScripted application. The user (a person) runs an AppleScripted application that tells Mail to do a series of steps that takes some time to complete. The user (person) forgets that the application (other user) is running and tries to operate Mail causing greate confusion and error to the other user.
>
> When the AppleScripted application is launched, it ought to be able to first tell Mail to become "Busy" and display a visual indication of that state. In other words, the AppleScripted application now owns Mail exclusively and no other user, neither a person nor a script, can operate Mail. When the owning application is finished, it releases ownership of Mail and other scripts or persons can now operate Mail.
Ah. The user vs. script battle is where AppleScript's thread-safe provisions ARE circumvented. AS can't possibly know what some foolish user is up to, so collisions are almost guaranteed. I like the idea of applying a "lock" to an application that's under script control, but only if it's one that I, as the programmer, could set and release in my code. Maybe something like this:
tell application "Mail"
disallow user input
...do stuff
allow user input
end tell
As for an automatic locking mechanism, I see some potential pitfalls. First, the lock probably shouldn't be popping on and off with the arrival and completion of every Apple event. Second, I don't like the idea of a timed lock that remains in force for some fixed time following each event. (And whether timed or untimed, if an event fails, would the lock ever release?) Third, it would need to lock out only the GUI, if that's possible, but not other Apple events, since those are already regulated by built-in thread-safety.
Finally, it may not even be possible to do on a system-wide basis, considering the diversity of implementations among scriptable applications. It may fall solely within the realm of application developers to include (or not) such functionality. Adobe InDesign, for example, has the 'user interaction level' command, which limits output to, but unfortunatley not input from, the user.
I should add a disclaimer. My knowledge of all this stuff is quite limited, so consider these thoughts to be speculations that may, or may not, have much basis in reality. If nothing else, there's always user education--don't touch the dang machine while a script is running!!!
Stan C.
_______________________________________________
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