Persistent Properties for Applescripts run from Quicksilver

[Edog]

I'm trying get an Applescript to run from a Quicksilver / Abracadabra
trigger. Much to my disappointment, it appears that Applescripts run
from within Quicksilver do not have persistent properties, that is the
property values are lost between script runs.

Does anyone know a sneaky way around this problem, or will I be
required to create a. plist file for my rather complicated set of
properties?

[Jon Stovell (a.k.a. Sesquipedalian)]

Searching for "applescript properties" discovers this:

http://groups.google.com/group/blacktree-quicksilver/browse_thread/thread/15aee4dfbff057ea/0a9bc3b2c8b755d8?lnk=gst&q=applescript+properties#0a9bc3b2c8b755d8

Scroll down a few posts for the relevant discussion.

[Edog]

Thank you for your response. I did see that posting, but in my first
reading I didn't find anything in it that wasn't pretty clear: namely
that using normal methods Applescripts launched from within
Quicksilver do not have properties that retain their values between
runs, and that one one way around this problem is to store the
properties in a text file or (a fancier text file) a .plist file. As
touched on in my question, my persistent properties are a complicated
mess of interrelated data with different data types. A text file or a
property list file would be a headache to set up.

Gathering I must have missed something, I read that posting again. I
realize after digging deeper that the scripter used Keychain scripting
to resolve his persistent property problem. I'm guessing that is what
you saw as the relevant part of the posting. While that approach was
clearly an ideal solution in that case, I don't think it is suited to
my problem.

However, I did go on to read a comprehensive and very well written
tutorial on the Applescript's Read and Write commands at MacScripter:

http://macscripter.net/viewtopic.php?id=24745

Joy, it seems that Write can store a complicated, nested AppleScript
list full of different data types in a file, and the Read command can
read the list from the file without difficulty in its full AppleScript
glory. So, I can pack my property values willy-nilly into a list,
store the list on a file, and, on the next script run, read the list
to repopulate my properties.

On Feb 2, 4:36 pm, "Jon Stovell (a.k.a. Sesquipedalian)"

<jonstov...@gmail.com> wrote:
> Searching for "applescript properties" discovers this:
>

> http://groups.google.com/group/blacktree-quicksilver/browse_thread/th...

[Jon Stovell (a.k.a. Sesquipedalian)]

No, my intention was not to suggest keychain scripting as a solution,
but to point you to a reference that explains exactly what the problem
is. (I was brief because I was busy at the time.)

However, rather than the read and write commands as described in the
(old) post that you linked to, I highly recommend creating a plist
file for storing your data. In Leopard and above, creating and
altering plists with AppleScript is trivial, and it will be much
faster than that method. See here: http://www.macosxautomation.com/applescript/features/propertylists.html

[Edog]

It turns out there is a sneaky way around this problem: To use an
Applescript which has persistent properties from within Quicksilver,
simply save the script as an application and use XCode's Property List
Editor to edit the info.plist file found inside the application
bundle. Add a child to the "Information Property List", choose
"Application is background only" from the drop down list, and click in
the check box. Now, you can activate the script/applet from within
Quicksilver, and it will still retain its persistent properties.