Re: Dialog from script application displays raw codes
Re: Dialog from script application displays raw codes
- Subject: Re: Dialog from script application displays raw codes
- From: "Steven D. Majewski" <email@hidden>
- Date: Wed, 30 Aug 2006 16:29:31 -0400
I've run into several problems with applications ( iView for one )
that change their AS dictionaries and terminologies
with a new release. Not only do my old scripts break, but I can no
longer read what they are doing where they are
broken because the terms have been removed and they now display in
the Script Editor as <<class ... >> and
<<event ... >>, and sometimes the four letter codes don't even
suggest a good guess.
I had to remove the new version of the apps, re-install the old
versions, run script editor and save a text version
of the script for reference before reinstalling the new version again.
For a while, I tried getting into the habit of saving scripts as
both, but it became a pain to make sure they were
both up to date or that I was editing the correct file.
It would be handy if Script Editor had an option to also save a text
backup copy along with the compiled script.
It would also be nice if application programmers who make large
changes to the AS terminology keep the
old definitions in the dictionary and mark them as obsolete, rather
than entirely removing them.
-- Steve Majewski
On Aug 30, 2006, at 3:47 PM, Christopher Nebel wrote:
On Aug 29, 2006, at 4:00 PM, has wrote:
we need a way of forcing the compiler to decompile raw codes like
«class cfol» and «class docf» into their more readily recognised
terms: "folder" or "document file"
is incorrect, because the compiler is not involved in runtime
conversions of AE codes to their human-readable equivalents. It's
the interpreter that's coercing your type classes to strings. What
your 'run script' trick does is ensure that the Finder's
terminology will be available for the interpreter to use when it
performs that coercion.
Mind you, if AS were smarter, it'd store the pre-parsed keyword-
code translations for application-defined class and constant names
within the compiled script. That way the interpreter would always
have access to that information when coercing type classes and
constants to strings. Probably a bit late to file a feature
request now though. :)
In fact, the whole identifier-to-string coercion feature was a not-
very-well-thought-out hack that was created mainly so people could
coerce weekday identifiers to strings. In some sense, any such
operation is a bad idea, because it's inherently English-only. Of
course, a lot of AppleScript users don't care, since they speak
English real good and don't plan to give their script to anyone who
doesn't.
--Chris Nebel
AppleScript Engineering
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden