You are not logged in.
Scripting System Preferences
The Mac is widely regarded as the computer of choice for creativity. It is often at the centre of a wide variety of pursuits, from music to movies, from illustration to photography or from design to desktop publishing. And at the heart of the Mac is Mac OS X, helping us to be more productive by making the creative process more effortless, enjoyable and effective.
To allow us work and play in our own, individual way, the Mac OS has long allowed extensive customisation. While such features were originally accessed through a collection of control panels in the control panels folder, Mac OS X introduced a single application to bring together most of the system customisation tools: System Preferences.
The aim of this article is to explore some of the ways in which we might use AppleScript to change certain system settings.
About System Preferences
System Preferences offers a wide range of options to control the system. Even when a Mac is shared by several users, each person can customise his or her experience and maintain most settings separately. The controls are grouped together quite logically and presented in a clear, graphical form so that even a relative novice should have little difficulty understanding how to use them.
System Preferences' preference panes include:
* .Mac used to set preferences for the users .Mac account and iDisk
* Accounts user creation/deletion, administrator privileges and user limitations are set here
* Appearance changes the general color of the OS as well as placement of Scroll arrows and Font Smoothing
* Bluetooth pair Bluetooth devices, edit Bluetooth settings
* CDs & DVDs used to set default settings upon inserting blank CD/DVDs, as well as music CDs, Picture CDs and Video DVDs
* Classic used to activate the Classic environment as well as set up settings for the Classic environment
* Date & Time used to set the Date & Time of the computer, as well as how the clock appears on the menu bar
* Desktop & Screensaver used to set the Desktop Picture as well as the screensaver, and there settings
* Displays set screen resolution and Color settings here
* Dock adjust the dock size as well as magnification and position on screen
* Energy Saver optimize energy settings as well as sleep times and processor usage
* Expos set Active Screen Corners and Keyboard and Mouse settings to activate Expos
* Ink set handwriting recognition settings
* International set the default OS language as well as numerical formats
* Keyboard & Mouse set keyboard settings, as well as change keyboard shortcuts, and mouse settings
* Network set Ethernet, AirPort, Modem and VPN Settings
* Print & Fax set the default Printer as well as fax settings
* QuickTime set Network speeds, plug-in settings, update, and register Quicktime here
* Security set FileVault settings, set up a Master password and set Account Security Settings
* Share set firewall and computer services preferences
* Software Update set default times to check for updates, and view updates already installed
* Sound set Alert Sound, Volume and Input/Output option
* Speech set the computers Default Voice, set up Speech Recognition, and other Speech Settings
* Startup Disk set the default disk, Hard Drive or Otherwise, for the computer to boot into
* Universal Access make your computer more accessible for those with, sight, hearing and other impairments
* Other panes it's also possible to add preference panes to System Preferences with third-party software
Accessing System Settings with AppleScript
From a scripting point of view, System Preferences' bias towards the graphic user interface (GUI) seems to have been somewhat at the expense of direct scriptability. While it would be helpful to have more scripting support added in future, we have to do what we can with what's currently available.
Although there are a number of ways to access system defaults, each is limited to certain individual settings. Until relatively recently, there has been no way to access system settings in a more general way.
Fortunately another feature, introduced in Mac OS X 10.3, includes support for the control of the GUI via AppleScript by means of an enhanced version of the System Events application. The GUI Scripting architecture is based upon the Mac OS X accessibility frameworks, and provides alternative methods of querying and controlling the interfaces of many applications and of the Mac OS itself. This means that AppleScript scripts can select menu items, push buttons, enter text into text fields, and generally control the interfaces of most non-Classic applications.
So the main methods of getting and changing system settings now include:
* using a shell script to access specific defaults
* extracting and modifying data in a property list file
* using third-party software
* GUI scripting of the System Preferences application
Avoiding Potential Conflicts Between Access Methods
In spite of the availability of GUI scripting, it's often preferable to modify settings quietly in the background, using an alternative approach (where one exists).
When using other methods, particularly if directly modifying data in property list files, it's generally advisable to avoid potential conflicts by making sure the application normally used to access those files is not currently open while changes are made. Otherwise, there's a risk that the application could ignore (or even overwrite) any settings modified by other means.
In a number of cases, System Preferences may be left open and will simply reflect the changes being made (as it does, for example, with the techniques for Changing Power Management Settings suggested below). In other situations, a dialog sheet might be displayed to alert the user that some settings "have been changed by another application" (as with the method proposed for Changing Current Location, below if System Preferences' Network pane is selected). In addition, any attempts to change settings normally accessed through a dialog sheet (such as the "Schedule" options for Energy Saver) are likely to fail if that sheet is displayed at the time.
One way around such issues is to quit the application, if it's running. It's better to do this without a direct application tell statement which may actually cause an unlaunched application to open. Try using an indirect quit statement instead, such as:
Applescript:
quit application "System Preferences"
However, this doesn't consider that the user may currently be using the application involved. A more user-friendly approach might be to quit the application, make any changes using the alternative method chosen and then re-launch it (preferably reinstating previous window settings, etc).
Here's an example of such a routine for System Preferences:
Applescript:
to |get SysPrefs status|()
tell application "System Events"
if not (exists application process "System Preferences") then return {false, false, false, false, false, false, false}
tell button "OK" of sheet 1 of front window of application process "System Preferences" to if exists then click
set {class xpsa:show_all, class xpcp:selected_pane, class xppw:{bounds:b, miniaturized:m}} to properties of application "System Preferences"
set {frontmost:f, visible:v} to application process "System Preferences"
quit application "System Preferences"
repeat while exists application process "System Preferences"
delay 0.2
end repeat
end tell
{true, not show_all, selected_pane, b, m, f, v}
end |get SysPrefs status|
to |restore SysPrefs| to {app_open, pane_selected, selected_pane, b, m, f, v}
if app_open then tell (a reference to application "System Preferences")
launch
if pane_selected then set its class xpcp to selected_pane
tell its class xppw to set {bounds, miniaturized, visible} to {b, m, not m}
tell application "System Events" to tell application process "System Preferences"
set frontmost to f
if not v then set visible to v
end tell
end tell
end |restore SysPrefs|
set SysPrefs_status to |get SysPrefs status|()
(* set defaults/settings using an appropriate non-System Preferences method *)
|restore SysPrefs| to SysPrefs_status
Using a Shell Script to Access Specific Defaults
Some shell commands provide direct access to certain system settings. Using a shell in this way can be an effective method, since the effect is the same as changing the setting in System Preferences but without the application intruding on the user.
Since this isn't a shell tutorial, we can't go into too much detail here. However, I've included a couple of shell examples along with a brief description of how we might find and implement an appropriate shell tool to achieve our aim.
Finding and Using a Suitable Shell Command
For this, let's assume that we want to change the current location in our network preferences.
Our first task is to carry out a search, to see if we can locate a suitable tool. To do this, we could use the apropos command to search the 'whatis' database for possibly relevant strings. So let's launch Terminal and, in a new Terminal window, type (or paste) something like: apropos system location then press the enter or return key.
Whoa! While some searches may return an unhopeful nothing appropriate, others (like this one) can present a welter of information. However, let's remain undaunted and wade through what's there. About halfway down the mass of data, we should see an entry that looks like:
scselect(8) - Select system configuration location
Might this do the trick? Let's find out by reading the relevant man (on-line manual) page...
Back in Terminal, type or paste (in a new window, if preferred) the words: man scselect, and press enter or return. This should give us some useful information about the command including a synopsis (outlining forms of syntax) and description (which should tell us if we're on the right track). From the description shown here, I think we've found something that might do the trick...
One final point on this. To avoid potential confusion over the file location of the tool to which we're referring, it's a good idea to include the file path in our shell script. We can usually determine this with the which command either in Terminal, or using a script:
Applescript:
do shell script "which scselect"
--> "/usr/sbin/scselect"
Changing Current Location
As described above, instead of opening the Network pane in System Preferences to change the current location (system configuration set), we could simply use scselect.
Applescript:
do shell script "/usr/sbin/scselect 'required-location-name'"
Accessing Energy Saver Settings
Another useful shell command in this context is pmset, which can read and set power management settings (normally accessed manually through System Preferences' Energy Saver pane). Either method reads or writes settings stored in /Library/Preferences/SystemConfiguration/com.apple.PowerManagement.plist apart from scheduled power on/off events, which are stored in /Library/Preferences/SystemConfiguration/com.apple.AutoWake.plist.
The following guide to corresponding controls may help:
Applescript:
do shell script "/usr/bin/pmset -g"
To extract an individual setting, we could use grep:
Applescript:
last word of (do shell script "/usr/bin/pmset -g | grep -w sleep") as integer
Note that grep's -w (word-regexp) option is used here, to avoid any confusion with other arguments that could include the word "sleep" such as "disksleep" or "displaysleep".
Getting Scheduled Events
To determine any currently scheduled startup/wake and shutdown/sleep events:
Applescript:
do shell script "/usr/bin/pmset -g sched"
Changing Power Management Settings
To change power management settings, pmset must be run as root. In AppleScript terms, this means running it with administrator privileges, which would normally also require an administrator password either entered by the user or provided by the script itself. Where the current user is not an administrator, an administrator account name should also be included.
This, for example, should ask the user for an administrator password (if required), and set the computer to sleep when it is inactive for 30 minutes:
Applescript:
do shell script "pmset sleep 30" with administrator privileges
This should require no user input, and set the display to sleep when the computer is inactive for 20 minutes:
Applescript:
set admin_name to "adminName" (* modify as appropriate *)
set admin_password to "adminPassword" (* modify as appropriate *)
do shell script "pmset displaysleep 20" user name admin_name password admin_password with administrator privileges
Scheduling Repeating Power Events
Clicking the "Schedule" button in System Preferences Energy Saver calls up a dialog sheet in which startup/wake and shutdown/sleep events can be scheduled. These events are repeated at a specified time according to the selected repeat option which could be one of the following:
* Weekdays
* Weekends
* Every Day
* A particular day of the week
These options can also be set using pmset. As with System Preferences, pmset supports only one pair of repeating events at any time; a "power on" event (poweron, wake or wakeorpoweron) and a "power off" event (sleep or shutdown).
Date and time formats in pmset are MM/dd/yy HH:mm:ss (24 hour format). Weekdays are designated by a subset of MTWRFSU with each character representing a day of the week, Monday (M) thru Sunday (U).
The following examples assume that the appropriate administrator name and password have been set as indicated above.
Start up or wake Weekdays at 08:30
Applescript:
do shell script "pmset repeat wakeorpoweron MTWRF 08:30:00" user name admin_name password admin_password with administrator privileges
Start up or wake Weekends at 10:45
Applescript:
do shell script "pmset repeat wakeorpoweron SU 10:45:00" user name admin_name password admin_password with administrator privileges
Sleep Every Day at 21:00
Applescript:
do shell script "pmset repeat sleep MTWRFSU 21:00:00" user name admin_name password admin_password with administrator privileges
Shutdown Sunday at 12:15
Applescript:
do shell script "pmset repeat shutdown U 12:15:00" user name admin_name password admin_password with administrator privileges
The options available from pmset are slightly more flexible than those offered by System Preferences. However, while a non-standard combination of days can be selected using pmset, System Preferences will be unable to display such choices; the corresponding pop up button will appear to be blank.
Start up or wake Monday, Wednesday and Friday at 09:00
Applescript:
do shell script "pmset repeat wakeorpoweron MWF 09:00:00" user name admin_name password admin_password with administrator privileges
Scheduling Individual Power Events
In addition, pmset provides a way to schedule individual (non-repeating) events which, again, System Preferences will be unable to reflect in the GUI.
Start up or wake Sunday, December 31, 2006 at 23:59
Applescript:
do shell script "pmset schedule wakeorpoweron '12/31/06 23:59:00'" user name admin_name password admin_password with administrator privileges
Cancelling Scheduled Power Events
To cancel all repeating events:
Applescript:
do shell script "pmset repeat cancel" user name admin_name password admin_password with administrator privileges
To cancel an individual event (in this case, the one we scheduled earlier):
Applescript:
do shell script "pmset schedule cancel wakeorpoweron '12/31/06 23:59:00'" user name admin_name password admin_password with administrator privileges
Combining Power Management Commands
A range of values can be set with a single shell script, as demonstrated by this composite example:
Applescript:
set admin_name to "adminName" (* modify as appropriate *)
set admin_password to "adminPassword" (* modify as appropriate *)
do shell script "pmset sleep 30 displaysleep 20 disksleep 10 ring 1 womp 1 halfdim 1 autorestart 0 reduce 0 repeat wakeorpoweron MTWRF 09:00:00 sleep MTWRF 17:30:00" user name admin_name password admin_password with administrator privileges
Further Information
For more details, type man pmset in a Terminal window and press the enter or return key or see below for details of how to create a PDF file.
Creating Unix PDF Manuals
While the formatting preferences in Terminal can be adjusted, you may still wish to enhance the way in which man pages are presented. To improve the general readability of such documents, you might want to consider creating dedicated PDF files.
Something like this might help:
Applescript:
property man_folder : path to desktop (* modify alias path as required *)
property dflt_doc : "man"
to |open pdf manual| for shell_command
if (count shell_command) is 0 then return beep
set pdf_doc to shell_command & ".pdf"
tell application "Finder" to tell folder man_folder's file pdf_doc
if not (exists) then tell me to try
do shell script "/usr/bin/man -t " & quoted form of shell_command & " | /usr/bin/pstopdf -i -o " & quoted form of (POSIX path of man_folder & pdf_doc)
on error
return beep
end try
if exists then open
end tell
set dflt_doc to shell_command
end |open pdf manual|
|open pdf manual| for text returned of (display dialog "Open which Unix PDF manual?" default answer dflt_doc)
Extracting and Modifying Data in a Property List File
Extracting Data
Many system settings can be extracted from property list files, either using the defaults shell command, or by scripting with System Events' Property List Suite.
If, for example, we wanted to find out the current animation effect when minimizing windows, we could extract it from the Dock's plist file (~/Library/Preferences/com.apple.dock.plist).
The shell script method might look like this:
Applescript:
set min_effect to last word of (do shell script "defaults read com.apple.dock | grep mineffect")
--> "genie" or "scale"
An equivalent approach using System Events would look more like:
Applescript:
tell application "System Events" to set min_effect to value of property list item "mineffect" of property list file (preferences folder's path & "com.apple.dock.plist")
--> "genie" or "scale"
Many folks will, of course, be attracted by the brevity of a shell script for such an operation. However, before deciding on the most appropriate method for a given situation, remember that a more verbose routine using System Events can often be considerably faster than invoking a shell.
Modifying Data
In many cases, data in a plist file can also be modified although doing so may not actually change the current setting. This is mainly because a number of the settings stored in plist files are loaded into memory at startup/login. Since the version in memory is usually that which is subsequently used, changing the plist file will often have little or no effect.
Nevertheless, the technique can sometimes work so, before resorting to GUI scripting, it might be worth a try. In addition, not all settings are 'registered' in the way described and are picked up by certain applications when they launch.
Screen Saver settings, for instance, are checked by the ScreenSaverEngine application whenever it launches. So, to change the preferred Screen Saver module, we could run something like:
Applescript:
quit application "System Preferences"
set text item delimiters to {""}
tell application "System Events" to tell property list file (preferences folder's path & "ByHost:com.apple.screensaver." & words of (system info)'s primary Ethernet address & ".plist")
set value of property list item "modulePath" to "/System/Library/Screen Savers/Beach.slideSaver"
set value of property list item "moduleName" to "Beach"
end tell
Other applications, such as the Dock and SystemUIServer (which deals with any Apple menu items that appear to the right of the menu bar), might stay open after launch and wouldn't therefore be aware of a changed plist file setting. Nevertheless, if you're not averse to being a bit heavy-handed, you could always force the application to quit so that, when it re-launches (usually automatically), the new settings should take effect. (When trying this trick with the Dock, bear in mind that any minimized windows that it may contain will become maximized.)
Here's a short script, based on the earlier data extraction example, which toggles the window minimization effect:
Applescript:
quit application "System Preferences"
tell application "System Events" to tell property list file ((preferences folder's path) & "com.apple.dock.plist")'s property list item "mineffect"
if value is "Genie" then
set value to "scale"
else
set value to "Genie"
end if
end tell
quit application "Dock"
Using Third-Party Software
Sometimes, a third-party application or scripting addition (often referred to as an osax after its filename extension) can be useful for changing certain settings.
However, if you wish to run this kind of solution on any other machine, that will also need the same third-party software installed since it won't have been included as part of the standard install. (In other words, such an approach can't be described as "vanilla".) Remember, too, that scripting additions should be installed in one of the Scripting Additions folders: /Library/ScriptingAdditions/ or ~/Library/ScriptingAdditions/.
For these examples, let's assume that we want to change the sound output volume...
Requires Jon's Commands:
Applescript:
set sound volume to 200
Requires Extra Suites
Applescript:
tell application "Extra Suites" to ES set volume 100
Both of these utilities, along with many more, are available from scripting additions.
GUI Scripting of the System Preferences Application
As a relatively new technology, GUI scripting is by no means comprehensive or consistent in every circumstance but it can be invaluable for controlling applications that either do not have AppleScript support or are only partially scriptable.
Enabling GUI Scripting
By default, the accessibility frameworks are disabled. An administrative user can enable them by clicking the checkbox labelled Enable access for assistive devices, in the Universal Access System Preference pane, and entering their password in the resulting authentication dialog. Alternatively, in Mac OS X version 10.4 or later, access can be enabled using the AppleScript Utility (located in /Applications/AppleScript/).
In addition, if we have a script that relies on GUI scripting being enabled, we could even insert a handler like this:
Applescript:
to |enable GUI scripting|()
if (system attribute "sysv") < 4138 then display dialog "This script requires the installation of Mac OS X 10.3 or higher." buttons {"Cancel"} default button 1 with icon 2
tell application "System Events" to if not UI elements enabled then
tell me to display dialog "This script requires the built-in Graphic User Interface Scripting architecture of Mac OS X, which is currently disabled." & return & return & "Enable GUI Scripting now? (You may be asked to enter your password.)" buttons {"Cancel", "Enable"} default button 2 with icon 2
set UI elements enabled to true
if not UI elements enabled then error number -128
end if
end |enable GUI scripting|
|enable GUI scripting|()
Having made sure that it's enabled, we can now explore the delights of GUI scripting...
Some Drawbacks of GUI Scripting
Actually, before we do go on, perhaps I should mention that scripting via the GUI is not generally considered an ideal method. It has a number of potential disadvantages, and can be:
* slow it's sometimes necessary to wait for certain UI elements to appear, before they're accessible
* intrusive it may get in the way of whatever the user might be trying to do at any given moment
* susceptible the user could, by changing object focus, get in the script's way at any given moment
* unpredictable the UI structure of an object can change substantially between different software versions
* local-dependent variations in language, keyboard layout and certain other local settings may need to be considered
* complex identifying a specific target element, particularly one that's deeply nested, can be a tortuous process
As a last resort, though, GUI scripting can be remarkably effective. So if I haven't put you off completely by now, let's explore it a little further...
Opening the Required System Preferences Pane & Tab
Our first job is to open System Preferences, get to the required pane and, if it contains more than one tab, select the relevant one. For the sake of an example, let's say that we wanted to access the Output tab of the Sound preferences pane.
One way to achieve this might go something like:
Applescript:
activate application "System Preferences"
tell application "System Events"
tell application process "System Preferences"
tell window 1
click button "Show All" of group 1 of group 2 of tool bar 1 (* in case another pane is already open *)
tell button "Sound" of scroll area 1
repeat until exists (* wait until the object is accessible *)
delay 0.2
end repeat
click
end tell
tell radio button "Output" of tab group 1
repeat until exists (* wait until the object is accessible *)
delay 0.2
end repeat
click
end tell
end tell
end tell
end tell
Phew. And that's before we even begin to change any settings! (The script may also need considerable adjustment before it will work on a machine where English is not the primary language.)
However, in spite of its currently limited scripting support, this is at least one area in which System Preferences can help substantially. Compare the above routine with this much simpler approach:
Applescript:
tell application "System Preferences" to activate (reveal anchor "output" of pane id "com.apple.preference.sound")
Let's take a look at how that actually works...
In this context, the term anchor is an element of a pane within a System Preferences window. It has only one (read only) property: name. This is used to identify it when using the reveal command. The anchor element and the reveal command are both referred to in System Preferences' AS dictionary.
Some panes (such as those whose id is "com.apple.preference.general", "com.apple.preference.digihub.discs", "com.apple.preference.expose", "com.apple.preference.dock", "com.apple.preference.security" or "com.apple.preference.startupdisk") might have only a single anchor usually named "main".
So something like...
Applescript:
tell application "System Preferences" to activate (reveal anchor "main" of pane id "com.apple.preference.general")
... will have pretty much the same effect as:
Applescript:
tell application "System Preferences"
set current pane to pane id "com.apple.preference.general"
activate
end tell
Other panes might include a "main" anchor along with several others. For example, pane id "com.apple.preference.sound" contains 4 anchors: "main", "output", "input" and "effects". Revealing the "main" anchor will simply show the sound pane that was chosen previously. (This could be used if access to only the output volume slider was required since that's generally available in all variants of the sound pane.) Revealing the output, input and effects anchors will access the balance, input level and alert volume sliders, respectively.
In many cases, revealing an anchor can perform the equivalent function of selecting a tab. However, that's not always the case.
The following, for instance, effectively emulates the clicking of the "Hot Corners..." button of "Desktop & Screen Saver". So it will display the "Active Screen Corners" sheet.
Applescript:
tell application "System Preferences" to activate (reveal anchor "ScreenSaverPref_HotCorners" of pane id "com.apple.preference.desktopscreeneffect")
Accessing Items that Require Authentication
In other situations, revealing an anchor is about the only way to access certain elements. Anyone who has ever tried, via GUI scripting, to get into the Accounts/Login Options of System Preferences will know what a headache that can be.
But something like this (perhaps with more appropriate password precautions, if required) should do the trick:
Applescript:
property authentication_data : missing value
to get_data(d)
repeat
tell text returned of (display dialog "Enter the required " & d & ":" default answer "" with hidden answer) to if (count) > 0 then return it
end repeat
end get_data
to authenticate_changes() (* may need a few moments to execute *)
tell application "System Events" to tell window "Authenticate" of process "SecurityAgent"
tell group 1 to repeat with i from 1 to 2
set value of text field i to authentication_data's item i
end repeat
click button "OK" of group 2
end tell
end authenticate_changes
if authentication_data is missing value then set authentication_data to {get_data("name"), get_data("password")}
tell application "System Preferences" to set current pane to pane id "com.apple.preferences.users"
tell application "System Events" to tell button "Click the lock to make changes." of window 1 of process "System Preferences" to if exists then
click
my authenticate_changes()
end if
tell application "System Preferences" to activate (reveal anchor "loginOptionsPref" of pane id "com.apple.preferences.users")
Identifying Panes and Anchors
"Ah yes, that's all very well," I can hear you say. "But how do I identify preferences panes and anchors in the first place?"
Good question, although it's one that System Preferences can answer quite easily as demonstrated by this short example:
Applescript:
tell application "System Preferences"
activate
tell current pane to if it exists then
set pane_name to localized name
else
set pane_name to missing value
end if
set pane_name to (choose from list (get localized name of panes)
with prompt "Choose a pane:" default items pane_name)
if pane_name is false then error number -128
set pane_id to id of (first pane whose localized name is pane_name's beginning)
set anchor_name to (choose from list (get name of pane pane_id's anchors)
with prompt "Choose an anchor from " & pane_name & ":")
if anchor_name is false then error number -128
end tell
tell application "Script Editor"
activate
make document with properties {text:"tell application \"System Preferences\"
activate
reveal anchor \"" & anchor_name & "\" of pane id \"" & pane_id & "\"
end"}
end tell
Some GUI Elements Whose Values Don't Stick
In general, changing the values of system settings via GUI Scripting can work quite well. However, it's worth noting that some UI elements (notably certain sliders) appear to be Teflon-coated. Since their values are not entirely persistent, these are best set using an alternative method. They include:
kai
Offline
Wow! - this looks like a really helpful post.. but im stuck.. when I open the first script provided into debugger it has an error -
set {class xpsa:show_all, class xpcp:selected_pane, class xppw:{bounds:b, miniaturized:m}} to properties of application "System Preferences"
Expected “:â€, etc. but found identifier.
Offline
Everywhere where it says 'class' followed by a four-letter code, the expression should be enclosed in chevrons (eg. «class xpsa»). I'm sure kai would have included them originally, so presumably their absence is due to a change in this site's BBS software since then. I haven't had time to check over all the scripts or work out what the one you quoted's meant to do, but it should probably look like this:
Applescript:
to |get SysPrefs status|()
tell application "System Events"
if not (exists application process "System Preferences") then return {false, false, false, false, false, false, false}
tell button "OK" of sheet 1 of front window of application process "System Preferences" to if exists then click
set {«class xpsa»:show_all, «class xpcp»:selected_pane, «class xppw»:{bounds:b, miniaturized:m}} to properties of application "System Preferences"
set {frontmost:f, visible:v} to application process "System Preferences"
quit application "System Preferences"
repeat while exists application process "System Preferences"
delay 0.2
end repeat
end tell
{true, not show_all, selected_pane, b, m, f, v}
end |get SysPrefs status|
to |restore SysPrefs| to {app_open, pane_selected, selected_pane, b, m, f, v}
if app_open then tell (a reference to application "System Preferences")
launch
if pane_selected then set its «class xpcp» to selected_pane
tell its «class xppw» to set {bounds, miniaturized, visible} to {b, m, not m}
tell application "System Events" to tell application process "System Preferences"
set frontmost to f
if not v then set visible to v
end tell
end tell
end |restore SysPrefs|
set SysPrefs_status to |get SysPrefs status|()
(* set defaults/settings using an appropriate non-System Preferences method *)
|restore SysPrefs| to SysPrefs_status
NG
Online
I get Syntax error message"Expected end of line but found identifier" at the line with
"set start_position to mouse location". I am using the same code as OP.
Probably something has changed with Mountain lion which I tried on.
Thanks.
Model: MacBook Pro
Browser: Safari 536.26.17
Operating System: Mac OS X (10.8)
Offline