I’m having a weird problem here with writing user defaults. I’ve got the standard handler, ie:
on writeSettings()
tell user defaults
set contents of default entry "showtestwindow" to showtestwindow
-- etc
end tell
end writeSettings
When called from within the “on quit” handler it works as expected. However, when called from within an “on should close” handler for a window (and yes it’s connected and yes I checked that portion is actually being executed and the on writeSettings() handler is properly called) OR called after a clicked event (setting changed), the settings do no seem to be actually written.
How do I know? If I abort the script with the stop button OR kill the process in terminal and relaunch, the settings do not stick. The only way to get the settings to stick is to quit the application by triggering the “on quit handler”. Why is this a problem? I’m dealing with a faceless background application and the only way to quit it is either run a “quit” script or kill it.
Thanks. I thought I just did explain. It’s a faceless background application and there are two ways to quit it: 1) run a script that quits it, and 2) kill it in terminal or kill it in activity monitor or whatever. Of course 1) is recommended and works to save the preferences, but there’s no real issue for 2 either except that one.
Anyway sounds like what you said is right. however then what’s the point of writing user defaults any other time than “on quit”? I have other applications that I THOUGHT were saving preferences at other times, but I guess not. What if you had an application with a lot of settings and then had a system freeze and had to force restart your computer? why shouldn’t the settings be saved earlier?
You didn’t explain why, just that you “had to”. Why do you have to? What’s going on?
Jacques has already chimed in with the manual synchronize command, but it’s worth adding a note to answer your question here:
Disk activity is expensive, time-wise. Imagine your application synchronizing to disk every time a preference is changed, and sometimes the disk is busy writing some other data. Now your application is waiting to write its defaults data to disk, which means your user is sitting there while the computer finishes performing all the disk I/O tasks it’s been told to do. That sucks, especially when it’s possible for an application to alter defaults values at any time. In general, you don’t want to call a manual synchronize every time a preference is changed–just changes you think may be essential.
You don’t need to synchronize on quit. The application will do that on its own if you aren’t killing the process.
You still have not described this situation that requires synchronizing to disk before killing the process, so I still think you’re working around an underlying design flaw in your application.