Haunted script [was Re: Evaporating properties]
Haunted script [was Re: Evaporating properties]
- Subject: Haunted script [was Re: Evaporating properties]
- From: Nigel Garvey <email@hidden>
- Date: Thu, 8 Feb 2001 16:31:38 +0000
I've been looking at the following experimental script by Marc Myers,
which he posted here a couple of days ago because it was behaving
strangely:
>
global thePass, newFile
>
>
on run
>
set thePass to 0
>
end run
>
>
on idle
>
set thePass to thePass + 1
>
if thePass = 1 then
>
set theCnt to 16
>
set newScript to makeScript(theCnt as text)
>
set myFile to (path to me)
>
tell application "Finder"
>
set newFile to (duplicate myFile) as alias
With Mac OS 8.6, because of a bug, the above line has to be changed to:
duplicate file myFile
set newFile to (file ((myFile as text) & " copy")) as alias
>
set name of newFile to "New App"
>
end tell
>
store script newScript in newFile with replacing
>
return 2
>
else if thePass = 2 then
>
ignoring application responses
>
tell application (newFile as text) to run
>
end ignoring
>
return 2
>
else
>
tell me to quit
>
return
>
end if
>
end idle
>
>
on makeScript(theText)
>
script test
>
property occCnt : theText
>
on idle
>
activate
>
display dialog "It happened " & occCnt & " times."
>
set occCnt to ((occCnt as integer) + 1) as text
>
return 4
>
end idle
>
end script
>
end makeScript
The script makes a duplicate of its own application file, renames the
duplicate, stores the script produced by the makeScript() handler into
it, tells the newly created app to run, then quits. The new script
carries on displaying dialogs with an increased value of 'occCnt' on each
idle call. Marc's problem was that the new script ran perfectly when
first created, but immediately threw a type 1 error if run again by
itself. (I got a type 2 error when I tried it.) If its idle handler was
changed to a run handler, there'd be no error on subsequent run attempts
and the number series would continue as expected.
I concluded that the value of the property 'occCnt' wasn't being stored
with the script and worked out a solution (of which more in another post:
"Empathic script"). But this changes the question from "Why doesn't the
new script work a second time?" to "Why does it work the first time?" And
what difference does the idle handler make?
To test this, I removed the 'on idle', 'return 4', and 'end idle' lines,
recompiled the 'mother' script, and ran it again. Sure enough, the
generated script ran as expected on subsequent attempts. But the
interesting thing about its *first* run was that *two*, consecutively
numbered dialogs were displayed in succession (although there was now no
repeat mechanism) and that the script then quit (although it was
supposedly in a stay-open shell).
Suspecting an ongoing link between the mother app and the generated one,
I replaced the mother app's 'quit' command with 'beep' and 'return 2', so
that it would stay open and beep every two seconds. The generated script
this time displayed two dialogs as before on its first run, but stayed
open. The beep tempo became lumpy at this point and, on a whim, I brought
the mother script to the front and used Command-Q to quit it. The beeping
continued (!) - though more regularly. I then quit the generated script,
dragged the mother to the trash, and emptied the trash. When I
double-clicked the generated script again, it displayed the next number
in the series and - when the dialog was dismissed - started beeping at
two-second intervals! When this script is opened in Script Editor,
there's not a 'beep' or an 'idle' to be seen, yet that's exactly what it
does.
There are some obvious possible reasons for all this, but would any
experts care to give the definitive explanation? Is the generated script
sharing a body with its mother's ghost? {8-0
NG