MDFS::Docs.Comp.RISCOS.Choices Search

User choices and RISC OS

Applications should store user preferences and settings in choices files accessed with the Choices* set of system variables. Choices:AppName.* must be used to read settings, and <Choices$Write>.AppName.* must be used to save settings. Choices: will usually be set by the system to a comma-separated list of paths to choices locations, with <Choices$Write> at the beginning, so that any preferences that the user has saved are checked first.

Application Directory

The application directory should be considered read-only space. Applications should *not* save user preferences inside themselves. Any default or fall-back settings should be stored in the application directory. When the application is installed, the administrator may modify the default settings to be suitable to the system. I have spent the last twenty years administering networked systems, and one of my top hates is applications that write to themselves.

Single Choices File

The simplest system, which Z80Tube uses, is a single Choices file run when the application is booted or run. The default settings are in the !Boot or !Run file itself, and these are overridden by any user preferences by the final lines:
| Override with any local choices:
/Z80Tube:X /Choices:Z80Tube.Choices

I have tweeked my version of CPMFS to run a choices file. The end of the !Run file contains:

| Set any local choices:
/CPMFS:Resources.X /Choices:CPMFS.Choices
|
/CPMFS:!RunImage %*0
The Choices should be run before the !RunImage.

The X command executes a command and ignores any errors. It is best to not depend on the application running on a system with an X command built in, so it is best to put an X command in the application directory itself. You can use and distribute this X command here, which is 32bit clean, and also has a RISC OS 4 header.

Multiple Choices File

An application could use multiple choices files for more flexibility. !Boot could run Choices:AppName.Boot, !Run could run Choices:AppName.Run, etc. FTPc uses Choices:FTPc.Setup and Choices:FTPc.UserMenu.

Choices Application

On a networked system is it essential that a user's choices are seperate from other users' preferences. FRED shouldn't have their browser's homepage set to SHEILA's prefered homepage just because SHEILA was the last user to log on. I wrote a small Choices application that can sit in each user's home area which should be run on logon to ensure that Choices: points to that user's area. !Choices can also be used on a non-networked system to let multiple users share a single machine and maintain multiple preferences.

When !Choices is run or Double-Clicked on, it sets the Choices: path to start with that !Choices directory. When !Choices is Double-Clicked on with Ctrl held down, it removes that !Choices from the Choices path. !Choices is available here:

Choices.zip 4K


Update 26-Nov-2003:
!Choices checks Ctrl instead of Alt, and the hi-res sprites are correctly named!

Update 06-Sep-2006:
X now has a RISC OS 4 header and should be correctly validated on 32-bit systems.

Justin Fletcher has written a much better overview than I could on using the Choices system in {this document broken link} (local copy).


Last updated: 06-Sep-2006