Re: Scripter (The Program)
Re: Scripter (The Program)
- Subject: Re: Scripter (The Program)
- From: Bill Cheeseman <email@hidden>
- Date: Thu, 09 Nov 2000 07:25:19 -0500
on 11/9/00 3:22 AM, Richard 23 at email@hidden wrote:
>
Ok. Since several people are extolling the virtues of Scripter perhaps
>
someone who has the latest version could test something for me. I'd
>
like to know if the following legal techniques which work in every other
>
script editor still fail to compile in Scripter....
I'm happy to respond to your challenge. Some of your tests are illegal, and
Scripter is correct to catch your syntax error. One of Scripter's advantages
is that it employs stricter syntax checking than other products, and it is
showing its strength compared to other script editors in this regard by
refusing to compile some of your tests. You were misled by the fact that
Script Editor (and other script editors, I gather) incorrectly overlooked
your syntax error.
Keep an open mind while you work through the following. I think you'll end
up agreeing with me.
>
script ScriptObj
>
beep
>
end
This does compile with Scripter 2.5. And if you add "run script ScriptObj"
and run the script, it beeps. I've used this technique for years and never
noticed a problem with earlier versions of Scripter in this regard. I don't
have the old versions around any longer, so I can't test them to be sure.
>
on run
>
set my TestHandler to run script "TestHandler
>
on TestHandler(theName)
>
display dialog \"Hello, \" & theName
>
end"
>
TestHandler("R23")
>
end run
>
>
on TestHandler()
>
end TestHandler
This does not compile with Scripter 2.5, giving the
wrong-number-of-parameters error on TestHandler("R23") in the 6th line. And
it shouldn't compile; the error report is correct. The handler TestHandler()
is defined at the bottom as having no parameter (there is nothing between
the parentheses), yet you called it with a parameter, "R23". If you remove
the first statement (the long Run Script command) and try to compile what's
left, you get the same error, as you clearly should.
If you try the shorter version (without the Run Script statement) in Script
Editor, it will compile, but it will generate a runtime error when you run
it, complaining that R23 doesn't match the parameter list required by
TestHandler().
Scripter implements stricter syntax checking than other editors, and this is
a case where that facility comes into play. It is surely more useful to
discover this syntax error at compile time than at run time.
If you comment out the illegal statement, TestHandler("R23"), Scripter will
compile and run your script, returning a handler object from the Run Script
command, just as Script Editor does.
What misled you is the fact that Script Editor will compile and run the full
script. You misinterpreted the meaning of this when you concluded that it
proves your script to be correct. In fact, it demonstrates that Script
Editor has a problem. Script Editor executes the Run Script command
correctly but then fails to catch the parameter error in the last statement
-- even though it does catch the parameter error when the Run Script
statement is omitted.
What is happening is that Script Editor doesn't even call the last statement
in the full version of the script. You can confirm this by adding a command
to the TestHandler() handler, like Beep. Then run the script. It never
beeps, because TestHandler() is never called -- and therefore no runtime
error is generated. There's something wrong with Script Editor, here. Or
maybe it's a problem with the Run Script osax command, which I guess is
known to have problems.
At the risk of sounding preachy, I would like to suggest that some of the
confusion comes from your using the same name for the explicit handler, the
handler in the string, and the variable holding the string. They are in fact
three separate entities, and it would improve readability and understanding
to give them different names. I wonder if the variant of your script given
below reflects what you were trying to do. It compiles and runs identically
in both Scripter and Script Editor. Note that the two handlers are called
separately.
on run
set myScriptStr to "myHandler(\"R23\")
on myHandler(theName)
display dialog \"Hello, \" & theName
end"
run script myScriptStr
TestHandler() -- omit illegal ("R23")
end run
on TestHandler()
beep
end TestHandler
If you were trying to do what programmers might call "overloading" your
TestHandler() handler -- that is, to give two different handlers the same
name but different parameter lists -- the short answer is that AppleScript
simply doesn't support this technique. Other languages do, such as
Objective-C, but AppleScript wasn't designed to have these more complex
capabilities.
>
on run
>
set theObj to run script "me
>
on f(theName)
>
return \"Hello, \" & theName
>
end"
>
tell theObj to f("R23")
>
set my f to theObj's f
>
-- f("32R")
>
end run
>
>
on f()
>
end f
>
>
>
*** This won't compile...why? ***
See above. It's the same syntax error. Scripter is telling you the truth.
Script Editor is lying.
>
set theObj to run script "
>
script
>
on run
>
set theObj to run script \"me
>
on f(theName)
>
\\\"Hello, \\\" & theName
>
end f\"
>
tell theObj to f(\"R23\")
>
set my f to theObj's f
>
f(\"23R\")
>
end run
>
>
on f()
>
end f
>
end script"
>
>
>
set theValue to run theObj
>
--> "Hello, 23R"
>
>
tell theObj to f("this")
>
--> "Hello, this"
Ah, I was right about your objective. My reworking of your script, up near
the top of this long message, seems to do the same thing you did here, but
more simply. This works because you have run the two scripts by making two
different calls, each honoring the parameter list of its called handler.
>
If these work in the new version I would like to know.
>
Maybe I could then re-evaluate whether I'd like to upgrade.
I recommend that you upgrade. Scripter's more-stringent syntax checking
helps to overcome misunderstandings like this.
-
Bill Cheeseman, Quechee, Vermont <
mailto:email@hidden>
The AppleScript Sourcebook
<
http://www.AppleScriptSourcebook.com/>
Vermont Recipes-A Cocoa Cookbook
<
http://www.stepwise.com/Articles/VermontRecipes/>