|
Страница 11 из 12
------------------------------------------------------------ Q-95: Как хранить настройки программ. ------------------------------------------------------------
Нижеприведенный текст являет собой вольное изложение отдельных статей
февральского выпуска 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.
|