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)" <[email protected]> wrote: > Searching for "applescript properties" discovers this: > > http://groups.google.com/group/blacktree-quicksilver/browse_thread/th... > > Scroll down a few posts for the relevant discussion. > > On Feb 2, 1:21 am, Edog <[email protected]> wrote: > > > > > 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?
