On Dec 17, 2008, at 11:44 AM, Ed Stockly wrote:
But they do, because the additions system forces them to.
Well, that is what should be fixed. That's the bath water.
Exactly. That's why I'm discussing it here. To figure out exactly what is the bath water. Exactly what do scripts intentionally rely upon vs. incidentally rely upon?
And, it wouldn't be that useful because while a dialog is displayed the script halts operation. What would be really useful is the ability to shutout all user interaction while the script runs. I know that's something programmers shouldn't do, but it is something a Scripter might want to do to our own machines.
As Jon Pugh suggested in another message, the system-wide blocking window could allow the user to stop the script.
Today I watched someone rapidly typing Command-Period over and over in an attempt to stop a script running Script Editor. The script kept activating other applications, so it took several tries to get the Command-Period to go to Script Editor. If a script could say “I'm going to be controlling this computer”, not only would a blocking window prevent user interference, it could provide an easy way to stop the script without struggling to get the right application in front first.
>>>Correction: they *apparently* work. They work for certain cases, as long as scripting additions and applications don't change.
How is that different from anything AppleScript.We are totally at the mercy of Apple and our app developers and things often break from one release to another. OSAX have been one of the more reliable features of the technology over the years.
The point I've been trying to drive home is that you can write scripts in a way that has fewer dependencies on them. Especially, depending on them not conflicting with each other. By throwing everything into a “tell application …” block—or worse, nesting “tell application …” blocks—you make it more dependent on additions and applications not conflicting with each other.
There really isn't anything inspecific about sending an OSAX call to an app. We want a random number, or a date string, or a dialog or ascii character right there at that line of our script and we don't care what happens under the hood to provide it, we just want it.
Exactly. It's vague and unspecific, and therefore subject to the vagaries of the interactions between additions and applications. And your script runs slower.
As for developers, they've done a very remarkable job over the last dozen years or so avoiding terminology conflicts, and allowing OSAX commands to live inside their application tells. There's no reason to assume that suddenly they'll start dropping the ball.
And yet, conflicts, bugs and incompatible changes occur. If you write scripts in a way that is more explicit about intent, you will avoid them when they happen, and you will make it easier for script, application and addition developers to be able to determine when your scripts are doing something intentional that they need to maintain compatibility with.