Strange bugs and crashes with PrefsStorageLib

AppleScript
#1

I added saving preferences with PrefsStorageLib, and I am having all sorts of problems. For a while, the problems could not be replicated in a short example, but today I can replicate them. I have two computers, both running Catalina, and they show the same behavior: when I run this simple applet (below), sometimes I get an error that “The ‘prepare storage’ command was unable to initialize user defaults. Unknown error. … error (-2700)” and other times the program crashes with a stack/heap collision. This only happens with the “on open” handler, and only when I run the program as an applet, the bug never shows up when I run the applet from within Script Debugger.

Here is the strange thing: I was able to solve the problem by saving the file as text, and then compiling it with Script Editor. So I am currently thinking that this is some obscure bug in Script Debugger, but I really don’t understand.

Here is the applet

use AppleScript version "2.5"
use scripting additions
use script "PrefsStorageLib" version "1.1.0"

property pTemplate : missing value
property pTemplateModDate : missing value
property pFieldNames : missing value

on open droppedItems
	prepare storage for domain "com.alanharper.test2" without write lock
	--set pFieldNames to value for key "pFieldNames"
	--set pTemplateModDate to value for key "pTemplateModDate"
	--set pTemplate to alias for key "pTemplate"
	display dialog ((length of droppedItems) as text) & " items dropped"
 open

The “without write lock” is because I thought that might solve the problem. It seems to make no difference.

#2

Apple applets saved from Script Debugger should behave the same as those saved from Script Editor. It would be very useful if you could send samples showing the problem.

#3

Hi, Shane. I don’t know how to post compiled code. I also don’t know how to post links. You’ll either have to try compiling the code above and see if it shows the bug, or figure out how to contact me, and I’ll send it to you. I have already submitted this as a bug to LNSW, because I really do think it is bug.

#4

I’m more interested in a compiled app that doesn’t work and the same app compiled elsewhere that does work. In this case, the code is largely irrelevant.

if you have such samples, please email them to support for my attention. Thanks!

#5

I have. 12 more chars

#6

I’ve looked at your samples, and the problem is that you’re using the for domain parameter when you shouldn’t. Follow the examples in the docs:

	prepare storage for (path to me)

(The reason your applet fails is because the domain string you are passing matches the bundle ID of your applet. It worked when you saved it as a new app because you didn’t given the new app the same bundle ID.)

The for domain parameter is only for cases where you don’t want to match the host’s bundle ID.