- Discussion Topics
- Online Resources
- Other Resources
This is an old revision of the document!
Work in Progress.
ToDoList can store configuration data in either a common .INI file, or in the Registry. This is determined at by a user prompt at installation time.
The .ini file consists of sections and name/value pairs (also called key/values). The following is an example of the beginning of such a file:
[[keyboardshortcuts|KeyboardShortcuts]] NumItems=67 ShowCommandIDs=0
[[preferences|Preferences]] AddFilesToMRU=1 AddLoggedTimeToTimeSpent=1 AddLoggedTimeUnits=72
Most users don't care about the contents of the file, only its location. For a new installation, the default configuration file is ToDoList.ini, in the root folder along with the .exe and .dll files. At startup, the ToDoList.exe tests to see if its folder location is writable by trying to create a temporary file. If the folder is *not* writable then the .ini file will be saved to
<user> \Application Data\Abstractspoon\ToDoList
Some users save ToDoList into the Program Files folder, but this is not recommended. Depending on how the application is being run and system-specific permissions settings, Windows may transparently save the file to a different folder:
<user> \AppData\Local\VirtualStore\Program Files (x86)\ToDoList That can be confusing. The reason for this is that Windows is a multi-user environment, and most configuration data is unique per-user. So apps should never write configuration data to the one and only “Program Files” path because that's shared by all users. However, installing ToDoList under Program Files is a choice made by individuals (and completely understood) but as seen here there are technical consequences for that decision. To help with this common problem, Microsoft made it so that when an individual user runs an app that tries to save configuration data in the Program Files path, it may (depending on permissions) transparently save the file under the AppData VirtualStore folder. That avoids a collision of different user settings, and while useful, it's also confusing to those of us who just have one person per system.
After the first execution of the application, the file can be moved to any location. To use a config file from a non-default location, you need to specify where your file is in the command-line using the -i switch. For example:
C:\SpecialApps\ToDoList\ToDoList.exe -i "C:\Users\me\Documents\Tasks\ToDoListLive.ini"
That command line would usually be set as the Target in a desktop shortcut. Some users simultaneously run different versions of ToDoList (different executable path) with different .tdl files (as defined by .ini files), simply by clicking different shortcuts.
Some sections are broken up simply for convenience. For example, there are sections for Preferences, Preferences\AttribUse, Preferences\Colors, etc. And there are other sections which are based on a template, where each section is like the others but unique in its own way. For example“
[[keyboardshortcuts\item00|KeyboardShortcuts\Item00]] CmdID=57670 Shortcut=112
[[keyboardshortcuts\item01|KeyboardShortcuts\Item01]] CmdID=32934 Shortcut=131142
Those sections both define shortcuts. All KeyboardShortcuts sections look the same.
Notice that the KeyboardShortcuts section above defines NumItems=67. Looking into a .ini file you might see the sections listed like this:
[[keyboardshortcuts\item55|KeyboardShortcuts\Item55]] [[keyboardshortcuts\item56|KeyboardShortcuts\Item56]] [[keyboardshortcuts\item57|KeyboardShortcuts\Item57]] [[pos|Pos]] [[version|Version]] [[settings|Settings]] [[findtasks|FindTasks]] [[findtasks\searches|FindTasks\Searches]] [[updates|Updates]] [[keyboardshortcuts\item58|KeyboardShortcuts\Item58]] [[keyboardshortcuts\item59|KeyboardShortcuts\Item59]]
The order of the sections and the name/value pairs is not important. And sections do not need to be grouped together. This may be significant when looking in this file for sections and keys.