Re: Curious problem with Scripter
Re: Curious problem with Scripter
- Subject: Re: Curious problem with Scripter
- From: Richard 23 <email@hidden>
- Date: Thu, 26 Apr 2001 07:07:33 -0700
>
While working on a script using Scripter PE I found that if I use the
>
auto-step feature, or if I invoke the script from the application
>
(Eudora), I get an error (variable errMessage not defined). So to
>
find where I left such variable undefined, I use the step feature of
>
Scripter, carefully pressing the shift key to be sure I step into any
>
handler that is used by the script. The funny thing is that I can
>
run the whole script that way and I never have a problem. So if I
>
run it very slowly, step by step, the variable is defined, but if I
>
go quickly with the auto-step the variable is not defined. How can
>
that be?
I've already been raked over the coals for suggesting anything might
be wrong with or improved in Scripter so I won't go there... 8)
** CAUTION: EDITORIALIZING **
If you are offended by personal opinion, close your eyes and move on.
My answer would go something like this:
Because debugging AppleScript is basically a hack which may or may not
function like a script in the real world, eg, an applet shell, or
being run by an application using OSA. Much of the time, for simple
by-the-numbers scripting this is fine.
Although it seems like a contradiction, relying on "power tools"
does not make one a "power user", actually it can be quite the
opposite. For instance, a person who uses a wysiwyg editor to
generate html can get results but only a subset of what is possible
and often the resulting html is a nightmare of redundant formatting
...noise. Faced with editing these creations by hand can be a real
eye-opener!
While not exactly the same, I think it's worth pointing out that
relying on one third party tool or another, one's style and perception
of what is possible tends to be shaped by the limits of one's editor
of choice.
If the editor you're using can't handle a construct which is legal
and works in the real world, reporting an error where none should
exist, it's only natural to assume that's the final word.
The user makes a mental note not to do it again. This is ok, I
guess. Personally I'd prefer not to be restricted to a subset of
what's really possible. I can find enough true boundaries without
adding additional arbitrary limits.
While in your specific case this may just be a minor annoyance,
to be sure it can be a rather discomforting feeling when a lot of
time has gone into developing a project in such a tool only to find
that it doesn't work when run outside of the comfortable little
environment, at least not without a change or two (or more).
Let's just say that although sometimes quite useful, I have found
enough little inconsistencies in the "advanced" script editors to
stick close to Script Editor, warts and all. It seems to run scripts
closest to how they will perform in the wild, other than the annoying
"path to me" feature, one of my personal pet peeves.
Script Debugger does do path to me nearly right (if you set the
preferences to return path to document). One caveat relying upon
this: path to x normally returns an alias while SD returns a file
specification. It seems to be implementing a command handler which
doesn't include the optional "as" parameter. The result?
SD: (path to me = path to document option off)
path to me as string
--> "Private:AppleScript:Editors:Script Debugger 2.0:Script Debugger"
SD: (path to me = path to document option on)
path to me as string
--> file "Dev:Con 4"
applet:
path to me as string
--> "Dev:Con 4"
To make it work correctly in SD use parentheses:
(path to me) as string
--> "Dev:Con 4"
One benefit of SD is Mark Alldritt who tends to be quite responsive
to user concerns. I wouldn't be surprised if he chimes in and does
something about it (hopefully the solution does not involve beating
me to a pulp for bringing it up...) 8)
just a little unsolicited info...
It is too bad that there doesn't seem to be any real publicly
accessible debugging features built into AppleScript.
Universal Interfaces provides only these in the debugging category:
OSAGetProperty()
OSASetHandler()
OSAGetHandler()
OSAGetHandlerNames()
OSAGetAppTerminology()
ASSetProperty()
ASGetProperty()
ASSetHandler()
ASGetHandler()
ASGetAppTerminology()
NOTE: these are C functions so don't expect them to do anything in
AppleScript without a suitable interface.
R23