Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Последние темы форума

Показать новые сообщения »

Почтовая рассылка

Подписчиков: 11695
Последний выпуск: 19.06.2015

Как хранить настройки программ

Примечание. Все упоминаемые в статье модули, функции и т.п. относятся к 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.

Оставить комментарий

Комментарий:
можно использовать BB-коды
Максимальная длина комментария - 4000 символов.
 

Комментарии

1.
89K
16 февраля 2013 года
tempuser
0 / / 16.02.2013
Мне нравитсяМне не нравится
16 февраля 2013, 16:44:48
>>создает больше проблем как пользователю (тут должна быть запятая) так разработчику, нежели пользы
2.
Аноним
Мне нравитсяМне не нравится
20 апреля 2006, 18:49:29
2Proger_XP
Кодируй, как это происходит в SMTP и POP протоколах - MIME. Размер объектов вырастет приблизительно в 1,5 раза.
3.
Аноним
Мне нравитсяМне не нравится
12 ноября 2005, 07:45:56
Бинарныые файлы хороши тем что они что двочные данные имеют более высокий приоритет при загрузке чем данные в ASCII тексте.
Если надо хранить много данных а я видел довольно большие файлы то это идеальный вариант, текстовые файлы хороши для создания различных языковых модулей как в OPERE.
Подключил файл и наслаждайся, вон я поставил себе новую версию OPERA 8.50 скачал lng файл и наслаждаюсь русским интерфейсом.
4.
Аноним
Мне нравитсяМне не нравится
9 августа 2005, 13:27:43
Можно сохранять в обычном файле. В разделе type
добавить новый record или packed record(напрмер TConfig=record) и в туда добавить все объекты. В процедуре сохранения добавить переменную,например: t:file of TConfig, и еще одну переменную типа TConfig, затем вбивать в эту переменную все настройки. Если в ваших параметрах есть переменная типа string замените ее на char
5.
Аноним
Мне нравитсяМне не нравится
7 августа 2004, 22:25:53
Бинарные файлы настроек: а если мне дужно сохранить 3-4 объекта что же мне их в тексте хранить?
Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог