|
Примечание. Все упоминаемые в статье модули, функции и т.п. относятся
к Delphi.
Нижеприведенный текст являет собой вольное изложение отдельных статей
февральского выпуска Microsoft Platform SDK. Год 2001 от рождества Христова. При
проектировании способов хранения настроек своей программы следует задаться тремя
вопросами:
- Что хранить?
- Где хранить?
- Как хранить?
Что хранить
Поскольку первая часть вопроса нам известна по определению, т.е. хранить мы
будем настройки программы, то перейдем ко второй части вопроса. Ваша программа
устанавливается на КОМПЬЮТЕР а пользуются ей ПОЛЬЗОВАТЕЛИ. Соответственно все
настройки разделяются на две части а то и на все три - настройки которые
относятся к компьютеру в целом, настройки которые относятся ко всем локальным
пользователям, настройки которые относятся к конкретному пользовател. В
зависимости от специфики программы первая и вторая часть могут быть совмещены
или разделены. Поэтому важно сделать логическое разделение - какие настройки
вашей программы действительно специфичны для самого ПК, какие настройки должны
прилагаться ко всем пользователям, какие должны прилагаться к конкретному
пользователю. Кроме того Мокрософт рекомендует чтобы настройки учитывали
возможную мобильность пользователя, т.е. для пользователя находящегося в разных
местах, возможно потребуется иметь разные наборы настроек.
Где хранить
Вообще в голову приходят три вещи.
- Хранить настройки в системном реестре.
- Хранить настройки в каталоге куда установлена программа.
- Хранить настройки в системном каталоге Windows.
- Хранить настройка в домашнем каталоге пользователя.
В Windows имеется три места предназначенных для хранения настроек которыми и
следует пользоваться.
- Системный реестр.
- Домашний каталог пользователя (точнее один из его
подкаталогов).
- Общий каталог для пользователей.
Прочие мысли о местах хранения настроек должны быть выброшены из голов как
вредные и противоестественные, Microsoft уже за вас все придумала и нефиг
извращаться. Для тех кто не понимает почему, объясняю. На нормальной ОС (W\'NT,
W\'2K) программа обычно запускается от имени и с правами конкретного
пользователя. Обычно, если этот пользователь не является администратором, он
имеет право изменять содержимое следующих ресурсов:
- часть реестра HKEY_CURRENT_USER\\*
- содержимое своего домашнего каталога.
- содержимое временного каталога (который как правило
находится внутри домашнего).
- содержимое некого каталога или каталогов специально
выделенного для этого администратором.
При нормальном (читайте параноидальном) администрировании системы прочие места
либо доступны только в режиме чтения, либо вообще недоступны. В том числе и
папки \\Program Files и Windows. Посему любая попытка программы изменять любые
файловые ресурсы окромя вышеуказанных черевата тем что ее (программу) и его
(пользователя) пошлют подальше. Причем далеко не в самой вежливой форме.
Пример. Adobe Photoshop и его разработчики наивно полагают что им должны
быть выданы эксклюзивные права мусорить своими scratch-файлами в корневых
каталогах дисков, кроме того они полагают что им должна быть выдана в
пользование в режиме полный доступ часть системного реестра.. Временных
каталогов, специально выделенных для подобоного рода занятий, их не устраивает.
Как результат - Photoshop имеет серьезные проблемы с работой под Windows
NT/2000.
Системный реестр
С точки зрения хранения настроек программы системный реестр разделен на две
части. Это ветви HKEY_CURRENT_USER для хранения настроек специфичных для
пользователя, и HKEY_LOCAL_MACHINE для хранения настроек специфичных для всего
ПК и соответственно всех пользователей, работающих с этим ПК. Рекомендуемая
структура ветвей для хранения настроек программы -
HKEY_CURRENT_USER\\Software\\Company Name\\Application Name\\Version и
соответственно HKEY_LOCAL_MACHINE\\Software\\Company Name\\Application
Name\\Version. Параметры Company Name, Application Name, Version желательно не
хранить в виде hard-coded строк в коде программы а устанавливать в опциях
проекта (Project\\Options\\Version Info) и доставать впоследствии из ресурса с
помощью той же библиотеки RxLib. Альтернативный путь выбирать данные о версии
программы из ресурсов - использование Windows API (GetFileVersionInfo,
GetFileVersionInfoSize, VerQueryValue). Программе следует расчитывать на то что
доступ к подключам HKEY_LOCAL_MACHINE разрешен в режиме только для чтения, а
доступ к подключам HKEY_CURRENT_USER допускает чтение, изменение и создание
новых подключей и значений. Программе следует расчитывать на то что нужных ей
ключей может не оказаться в реестре или значения лежащие в реестре имеют
неверный формат или недопустимые значения. В таком случае, вместо несуществующих
или неверных значений настройки, программа должна использовать значения по
умолчанию которые разработчик может \"железно забить в код\" или получить с
помощью различных системных функций. Не следует использовать системный реестр
для хранения больших кусков данных. Вместо этого лучше хранить объемные данные в
отдельном файле, а в реестре запомнить имя этого файла.
Домашний каталог пользователя
Для хранения настроек слишком больших для того чтобы их размещать в реестре
существуют специально выделенные каталоги внутри домашнего каталога
пользователя. Эти каталоги обычно называются \"специальными каталогами\" и имеют
имена Application Data и Local Settings. Полный путь к ним можно получить с
помошью функций SHGetSpecialFolderPath или SHGetFolderPath.
Общий каталог пользователей
Обычно это каталог \"Documents and Settings\\All users\". Внутри него имеются
такие-же подкаталоги для хранения настроек и данных программ но относящихся ко
всем пользователям. Полный путь к ним можно также получить с помошью функций
SHGetSpecialFolderPath или SHGetFolderPath.
Как хранить
Системный реестр
Для работы с системным реестром можно использовать функции Registry API общим
числом около 40 штук, а можно использовать классы из Registry.pas - TRegistry,
TRegistryIniFile, TRegIniFile. Особенно следует обратить внимание на
TRegistryIniFile который предоставляет упрощенную модель доступа к системному
реестру очень схожую с моделью работы с INI-файлами.
INI-файлы
Это старый метод хранения настроек программ, но все еще применяющийся
программистами. Настройки хранятся в текстовом файле в виде:
[Section1]
Field1=Value1
Field2=Value2
...
FieldN=ValueN
[Section2]
Field1=Value1
Field2=Value2
...
FieldN=ValueN
...
[SectionN]
Field1=Value1
Field2=Value2
...
FieldN=ValueN
Для доступа к данным содержащимся в INI-файлах существуют классы из модуля
IniFiles - TIniFile, TMemIniFile. Преимущество использования INI-файлов состоит
в том что их можно легко подредактировать с помощью текстового редактора. Они
обычно легче воспринимаются для прочтения нежели дерево ключей системного
реестра.
Бинарные файлы настроек
Отдельно хочется поговорить о использовании бинарных файлов в качестве
хранилища для настроек программы. Обычные мотивы любителей использовать бинарные
файлы:
- Экономится место.
- Настройку можно спрятать от пользователя (сделать
нечитабельной).
Первое глупо потому что информация о настройке занимает обычно немного места
и экономия достигается мизерная. Второе глупо потому что невозможность просмотра
и редактирования настроечных данных простыми средствами (текстовый редактор) или
встроенными (редактор реестра) создает больше проблем как пользователю так
разработчику, нежели пользы (причем весьма сомнительной) от того что кто-то не
сможет прочитать что написано в файле. Кроме того использование бинарного файла
нельзя назвать защитой от нежелательного просмотра, т.к. любой \"продвинутый
пользователь\" все равно с помощью редактора бинарных файлов сможет просмотреть
и разобраться в содержимом настройки.
Заключение
Почти вся эта информация была вычерпана из кладезя мудрости под названием
Platform SDK (Software Development Kit), поставляемого в составе сборника
документации MSDN (Microsoft Software Developer Network). Разработчикам
настоятельно рекомендуется приобрести Platform SDK, это снимает огромную массу
вопросов связанную с программированием под Windows.
| 
