Properties not persistent in SD 8

Script Debugger
#1

Hello!
(First post here! Long time user, fairly new to SD 8.)

When running scripts with properties modified along the way, SD 8 resets the property when run again.
SD 7 keeps the properties’ new values. I hope there is an obvious solution to this but I can’t fint it.

It is easy (for me) to recreate the problem running this:

property p : 0

display dialog (p as Unicode text)
set p to (p + 1)
display dialog (p as Unicode text)

Running it more than once should display an increasing value (p), which it does in SD 7, but not in SD 8.

Edit: here is a film showing it:
drive dot google dot com/file/d/1h_x7NqFeGbo_MR9YRHXG_i8gCvereGo0/view?usp=sharing

#2

I see now that it is a feature. This makes my work harder and makes some debugging impossible.

#3

So, I might submit a feature request, something like a “Use persistent properties” toggle. I’d be happy enough if it could be active as long as the document is open, and I don’t need to save it for next session as long as I can do what I asked for in original post.

#4

The solution I’ve used for some time now is Shane’s PrefStorageLib found here: Freeware | Late Night Software

There have been several cases where older scripts crashed or failed silently because properties were not persistent between runs and I have a script that will add the code to any script in and open window to convert all properties to be saved using PrefStorageLib.

PrefsStorageLib 1.1.0

PrefsStorageLib is a library that makes it easy for scripts to store persistent values in their existing preference property list files using the standard application defaults system. This gets around the problem where applets cannot retain values between launches because they are notarized, or locked to avoid repeated authorization dialogs. Works with macOS 10.11 or later. (Updated March 11, 2020)

1 Like
#5

In addition to what @estockly has already said:

In general, if you need to preserve certain values (whether in a script or app in any language), they have to be stored and retrieved properly (whether in preferences, data source, text file etc.) I do understand that you took advantage of an existing option, and now you need to alter your workflow. But that approach was faulty from the start, if you ask me.

#6

Or take a look here: Storing Persistent Values in Preferences
or here.

#7

As others have written, relying on AppleScript property persistence is not a reliable way to persist information from one script execution to another. This AppleScript facility is vestigial and not universally available in all script run-time environments. Using Shane’s PrefStorageLib is probably the best approach, though there are others.

Following the security changes brought in macOS Mojave, AppleScript property persistence ceased to work in stand-alone applets. At that point we opted to remove property persistence from Script Debugger to create a runtime environment more closely aligned with what you’ll find when you deploy your scripts.

We understand this differs from how Apple’s Script Editor operates.

2 Likes
#8

Thank you all for good input! I knew most (or at least some) of it already, but might have a niche where persistent properties is a good compromise between reliability and ease of use (to me).
We have a workflow where a lot of Indesign users ger some scripts from an MDM system, Filewave, via a “launcher app” we have built, that starts the right Indesign version, installs preference files, mounts fileshares, retrieves indesign scripts and so on. Every time they run this launcher the users get a fresh set of scripts.
Some of them remembers the last choice from a list, or some value of some property, all for convenience. It is a bit of an overkill to use .plist files imho. Where we want the users to start off using default settings, persistent properties work fine. In other cases we use plist files.

#9

There is another approach to consider: loading/storing script objects that allows you pretend you are using persistent properties:

use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions

--	Where will we store the settings? (~/Library/Prefernces/com.mycompany.settings.scpt)
property settingsFile : POSIX file ((POSIX path of (path to preferences)) & "com.mycompany.settings.scpt")

--	Initial default values for settings
script settingsDefaults
	property setting1 : "Hello World"
	property setting2 : 100
end script

--	Load settings
try
	set settings to load script settingsFile
on error -- file not found, etc.
	copy settingsDefaults to settings
end try

--	Lets see what the setting's value is now...
display alert "setting1 is: " & settings's setting1 & ¬
	return & return & ¬
	"setting2 is: " & (settings's setting2)

--	Alter a setting
set settings's setting1 to (settings's setting1) & " " & (some item of {"Mark", "Jane", "Frank", "Sandy"})
set settings's setting2 to (settings's setting2) + 1

--	Save the updated setting to disk
store script settings in settingsFile replacing yes

Run this a few times and you’ll see it working. This will work reliably from any runtime environment.

#10

Yes, I use a similar method already for some more simple tasks. Thank you!