Re: Script Menu in Tiger: non-persistent property bug?
Re: Script Menu in Tiger: non-persistent property bug?
- Subject: Re: Script Menu in Tiger: non-persistent property bug?
- From: kai <email@hidden>
- Date: Thu, 11 Aug 2005 02:46:19 +0100
On 10 Aug 2005, at 17:25, Matt Neuburg wrote:
On Sun, 7 Aug 2005 13:06:05 +0100, kai <email@hidden> said:
One thing was puzzling me particularly: When run from the Script
Menu, some scripts were retaining changed properties - while others
weren't. All scripts worked as expected when run as an application,
or from Script Editor - but not (in every case) from the Script Menu.
After much digging (not to mention some head-banging), I believe that
I may have identified the differentiating factor between those
scripts that work correctly and those that don't. If the script
returns a value (almost any value, as far as I can tell), then
changed properties will persist. However, if the script's final
operation doesn't return a value, it's a rather different story.
Wow. Kai, this is really good work. Bravo.
Thanks, Matt.
And here I always thought (and my book documents) that persistence
simply
doesn't work in Apple's Script menu. But now it turns out that it
*can* be
made to work.
The reason I always thought it didn't work is that my test was
always a
display dialog of a property. That isn't enough to get the
persistence to
happen.
I can get a dialog to work, as long as it's the final statement (and
is not cancelled or wrapped in a conditional block). Since the
following dialog returns the record {button returned:"OK"}, that
seems to be sufficient here to maintain persistence:
--------------
property n : 0
set n to n + 1
display dialog "Test #" & n
--------------
Of course, as I discussed with Deivy, should persistence be required
regardless of errors, some trapping would be needed:
--------------
property n : 0
set n to n + 1
try
display dialog "Test #" & n
on error number -128
false (* or any other value *)
end try
--------------
Now I'm going to have to go back and test all the *other* places
where I say
persistence doesn't work.
Sorry, Matt. My apologies for adding to your workload. ;-)
By the way, it does work in applets and in FastScripts menu.
Right - the issue does seem to be confined to the Script Menu.
I still think my book is right to say, however, that persistence is a
problem because it is implemented in a troublesomely inconsistent way,
working only in some milieus and not in others.
Absolutely. Inconsistency seems a fair criterion for regarding a
given behaviour as unintentional/buggy. Adding a try block to the
above snippet might have been a simple matter. But trapping every
potential error or null result in a complex script may not be quite
so trivial - and really shouldn't be necessary just to ensure that
property values persist.
The worst offender is of
course the Script Editor itself which now strips persistent
information when
you open a script for editing (even if you don't change the
script). It
didn't do this back on OS 9 and before. (And Script Debugger still
doesn't.)
It seems almost as if Script Editor now opens a separate instance of
the script, rather than the one stored in the file.
When I run the above script several times from a file (either an
applet or a compiled script run from the Script Menu), it works as
one might expect, returning:
--> Test #1
--> Test #2
--> Test #3
--> Test #4
--> Test #5
--> Test #6
If I then open and run the file a few times in Script Editor, it
behaves as if it has been freshly compiled - so I get:
--> Test #1
--> Test #2
--> Test #3
When, after closing the SE document without saving, I run the script
again from the file - it continues from where the file version left off:
--> Test #7
--> Test #8
--> Test #9
However, when the script is saved after being run in Script Editor,
running it from the file continues from where the SE version left off:
--> Test #4
--> Test #5
--> Test #6
So the file version recognises changed property values from a saved
SE run, but SE apparently ignores these each time it opens the file.
As you say, the behaviour previously was that a script's properties
would always contain the latest saved values - regardless of which
application last ran the script. Property values were only
reinitialised when a script was recompiled.
(The pre-OS X Script Editor would also regard any script that it had
run as modified - and offer to save on closing. This no longer
appears to be the case, either.)
It seems to me that the earlier behaviour of Script Editor is the
more desirable. Do you happen to know if a bug has been filed on any
of this?
---
kai
_______________________________________________
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