Нынче практически любая мало-мальски полезная программа имеет возможность выполнить настройку особенностей своей работы и/или своего внешнего вида. Для этого, как правило, используется диалог установки параметров. При использовании интерфейса, выполненного в соответствии с общепринятыми стандартами, вызвать такой диалог наверняка можно с помощью команд меню наподобие "Service/Options...", " View/Options..." или "File/Preferences...". Соответственно, и диалоги имеют наименование "Options" или "Preferences". При использовании русскоязычного интерфейса используются аналогичные наименования - "Параметры", "Установки". Отход от сложившихся стандартов обычно воспринимается пользователями негативно. Удобно, когда находишь то, что тебе надо, там, где ожидаешь найти, без необходимости рыться в справке или руководстве.

Если настроек много, то для управления ими приходится использовать многостраничные диалоги. При использовании простейшего дизайна применяется многокорешковый блокнот как в диалоге "Internet Options" браузера Internet Explorer, в других случаях это может быть блокнот, управляемый вместо корешков списком строк или пиктограмм, как, например, в диалоге "Preferences" браузера Opera и т.п. (обычно этот список располагается слева).

Так что если у вас есть программа, которая выполняет некоторую полезную работу, то удобство работы с ней можно увеличить простым введением настроек. Даже такие, казалось бы, примитивные и легко программируемые настройки, как наличие/отсутствие значков в меню, видимость/невидимость тех или иных панелей инструментов и т.п., улучшают восприятие продукта. Ну а уж о более продвинутых настройках и говорить нечего, поскольку они не просто добавляют в программу "бантики", а расширяют ее функциональность.

Но все сказанное касается больше вопросов дизайна и эргономики программы. Теперь же рассмотрим технологическую сторону вопроса.

Независимо от того, как реализован диалог управления параметрами с точки зрения дизайна, задачи реализации механизма настроек одинаковы. При первом запуске программы на машине пользователя необходимо загрузить (или задать) значения установок по умолчанию, при работе программы дать возможность пользователю изменить настройки (с изменением характеристик, соответствующих проведенным изменениям - перестройкой внешнего вида, изменением режимов работы и т.п.), сохранить настройки на диске для дальнейшего использования программы после ее рестарта. Если вы выпускаете новую версию своего продукта, то к этим задачам может добавиться небходимость учесть настройки (все или только некоторые) прежней версии.

Вначале определимся со способом хранения настроек. Параметры программы обычно сохраняются или в ini-файлах, или в реестре. В 16-разрядных версиях Windows ini-файлы были основным хранилищем настроек. Несмотря на то, что в 32-разрядных версиях для хранения параметров программ Microsoft рекомендовала использовать реестр, ini-файлы также широко применяются программистами для хранения настроек. И дело здесь не только в устоявшейся привычке - использование ini-файлов имеет свои преимущества, а в некоторых случаях хранение настроек в отдельно лежащих файлах является единственным приемлемым решением. При использовании реестра удобно сохранять разные настройки одной и той же программы для разных пользователей (сохраняя их в ветви HKEY_CURRENT_USER). То же самое можно сделать и с помощью файлов, размещая их в папке данных программы (определяется вызовом функции SHGetFolderPath() с параметром CSIDL_APPDATA и размещением по этому пути папки с именем программы; впрочем, есть и иные варианты размещения).

Если пользователь один, а на компьютере установлено несколько операционных систем, то удобнее, когда настройки хранятся в ini-файле. Это избавляет от необходимости выполнять одни и те же действия по настройке под разными системами (что весьма неприятно, если таких настроек много). Однако следует внимательно отнестись к месту размещения ini-файла настроек: в Windows NT у пользователя может не быть соответствующих прав на некоторые папки (например, в папке установки программы). Хорошо выглядит решение, реализованное в файловом менеджере FAR: настройки хранятся в реестре, а в случае необходимости их переноса из одной операционной системы в другую используются два bat-файла для выгрузки и загрузки, соответственно, SaveSettings.bat и RestoreSettings.bat. Первый делает "снимок" требуемых ветвей реестра в файл, а второй проделывает обратную работу.

Существует еще один интересный момент, связанный с установкой программы на подключаемое устройство - например, на флэш-карту. В этом случае настройки разумно сохранять на самом устройстве. Естественно сохранять параметры в этом случае в ini-файлах (впрочем, можно использовать не только ini-формат).

Вместе с тем информация о расширениях файлов сохраняется в реестре, так что при использовании хранения настроек в файлах от реестра не уйти, если используется регистрация расширений. Если же ваша программа устанавливается на флэш-карту, то здесь нужно еще подумать, стоит ли регистрировать расширение. Почему - думаю, понятно.

Решать задачу реализации механизма настроек можно по-разному. Можно, особенно себя не утруждая программированием, порыться в интернете в поисках готовых универсальных решений. Если ваш проект большой, то лишние пару сотен килобайт, которые может съесть такое решение, скорее всего, не напрягут. Если же проект небольшой, то это может заставить искать менее универсальное, но зато более компактное решение.

Можно все запрограммировать "в лоб": создаем список переменных для хранения параметров (которые могут быть скомпонованы в запись или даже в класс), затем поочередно читаем параметр с таким-то именем, записываем в такую-то переменную и т.д. Когда параметров становится много, то код разрастается самым неоптимальным образом. Автоматизация процессов чтения (и записи) ведет к накладным расходам по хранению имен и типов параметров, на обеспечение соответствия имен параметров переменным, в которых они сохраняются. В общем, хотелось бы компактно, но универсально.

Современные системы программирования используют базовые библиотеки классов, предоставляющие возможность использования RTTI - информация о типах во время выполнения и сериализации (сохранения и чтения свойств) объектов. Эти механизмы можно задействовать для сохранения и загрузки параметров. Их использование избавит от необходимости держать отдельно имена параметров в виде строк и отслеживать соответствие этих имен конкретным переменным - именами параметров станут имена свойств класса. Ну а класс-холдер настроек придется написать вручную. Использование такого класса позволит передавать весь набор настроек как параметр в функции. Создавая субклассы настроек и объединяя их в классе-контейнере параметров, можно придать более логичный и понятный вид иерархии настроек. Это также требует работы. Но после некоторых усилий у вас будет приемлемое компактное решение :).

Удачи!

Юрий А. СМАНЦЕР,
georgesman@mail.ru