4 какой файл отвечает за хранение пользовательских настроек

Обновлено: 04.07.2024

Настройки пользователя в 1С обычно разделены на три части.

Во-первых, платформа 1С позволяет каждому пользователю делать свои собственные настройки 1С для удобства. Например, настройки 1С отчетов СКД.

Во-вторых, в каждой типовой и не типовой конфигурации обычно есть много обработок, которые выполняют сервисные действия. Обработки требуют настройки. Жалко терять время, заново вводя настройки при каждом открытии обработки.

И наконец в-третьих, самому программисту, чтобы программа была универсальна, некоторые значения по-умолчанию лучше не прописывать в коде программы, а хранить в каких-либо настройках.

Где хранить все эти настройки в 1С?

Как настройки 1С сохраняли раньше

В толстом клиенте 1С платформа предлагала следующий стандартный вариант:

  • Когда требуется запомнить настройку 1С, программист использует функцию
    СохранитьЗначение(«ИмяНастройки», Значение);
  • Чтобы прочитать настройку 1С, используется функция
    Значение = ВосстановитьЗначение(«ИмяНастройки», Значение);

Соответственно программист создает кнопки сохранения и восстановления настроек 1С, а пользователь использует этот механизм (ну или программист сохраняет их автоматически).

В качестве значения можно использовать не только число или строку, но и например Структуру – тип, который позволяет хранить в себе множество значений с их наименованиями, например:
Настройки = Новый Структура();
Настройки.Вставить(«ИмяНастройки», Значение);
Значение = Настройки.ИмяНастройки;

Настройка 1С сохраняется для того пользователя, который нажал разработанную программистом кнопку сохранения настроек 1С (или под которым эти действия выполнились автоматически). Настройки 1С хранятся при этом в текстом файле в папке с базой данных (при использовании файловой базы данных).

Также программист был волен разрабатывать свои произвольные методы хранения настроек 1С с использованием обычных методов – например, с помощью работы с текстовыми и XML файлами – сохранять настройки 1С произвольным образом в файл.

В типовых конфигурациях настройки 1С отчетов сохранялись в регистр сведений. А настройки 1С отчетов СКД можно сохранить в файл XML.

Стандартное хранилище настроек 1С

Все эти возможности остались и в новой платформе 8.2, но появился наконец некий «стандартный метод» сохранения настроек – Хранилище настроек 1С.

Механизм делится на две части – стандартные и пользовательские хранилища настроек 1С. Стандартное реализовано в платформе 1С, пользовательские – это объект 1С, который создает и программирует программист.

Стандартное хранилище настроек 1С используется платформой по умолчанию в тонком клиенте для сохранения настроек 1С пользователя в следующих механизмах платформы:

  • Командный управляемый интерфейс
  • Формы
  • Настройки и варианты отчетов.

Программист может использовать стандартное хранилище настроек 1С из кода программ на языке 1С способом, подобным тому, что был раньше:

  • Когда требуется запомнить настройку
    ХранилищеОбщихНастроек.Сохранить("ИмяОбъекта", "ИмяНастроек", Значение);
  • Чтобы прочитать настройку
    Значение = ХранилищеОбщихНастроек.Загрузить("ИмяОбъекта", "ИмяНастроек", Значение);
  • Чтобы получить список настроек
    Список = ХранилищеОбщихНастроек.ПолучитьСписок("ИмяОбъекта");

Настройки 1С сохраняются непосредственно в базе данных, в специальных таблицах.

Как видно, по сравнению со старым механизмом, добавился дополнительный разрез – имя объекта. Платформа, при автоматическом сохранении используется имя объекта 1С в метаданных с указанием вида, например:
Отчет.Продажи

Также появилась возможность управлять именем пользователя, для которого будут сохранены настройки 1С, указав его последним параметром.

Существуют следующие стандартные хранилища настроек 1С:

  • ХранилищеСистемныхНастроек
  • ХранилищеОбщихНастроек
  • ХранилищеНастроекДанныхФорм
  • ХранилищеПользовательскихНастроекОтчетов и ХранилищеВариантовОтчетов.

Хранилище настроек 1С

Программист может создать собственные хранилища настроек – в конфигураторе.

Это предполагается делать в следующих случаях:

  • Ссылочный контроль при хранении настроек 1С
  • Миграция настроек 1С при использовании УРБД
  • Специальная структура настроек 1С (для автоматического ее соблюдения)
  • Переопределение стандартных хранилищ.

Для создания собственного хранилища настроек 1С – необходимо добавить таковое в конфигураторе в окне конфигурации в ветке Общие/Хранилища настроек 1С.


Переопределить стандартные хранилища настроек 1С, используемые платформой можно в свойствах конфигурации (корневой ветки конфигурации, которую программисты обычно называют Корень или Голова).

Если в свойствах пустая строка – используется стандартное хранилище настроек 1С, иначе – используется выбранное, а стандартное не используется.


В тонком управляемом клиенте 1С использование хранилища возможно автоматически:

    В управляемой форме есть два параметра
    o Автоматическое сохранение данных – будет проводиться автоматически, в стандартное хранилище настроек форм
    o Сохранение данных в настройках 1С – использовать список – в списке реквизитов формы появится колонка Сохранение, в которой можно проставить галочки, который будут сохраняться, а также можно указать созданное хранилище настроек

В толстом клиенте для использования требуется в коде на языке 1С прописывать непосредственный вызов сохранения настроек 1С:
ХранилищаНастроек.ИмяХранилища.Сохранить();

При добавлении в конфигурацию собственного хранилища настроек 1С требуется на языке 1С прописать обработчики загрузки и сохранения значений, иначе хранилище работать не будет.

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

В интернете приведено очень много способов хранения настроек программы, но все они как-то разбросаны, поэтому я решил их собрать вместе и расписать, как этим пользоваться.

На хабре уже была посвящена этому тема, поэтому… перейти

Информация о Properties.Settings

Организация Properties.Settings — это обычный xml файл, который можно найти в папке пользователя:

С:\ Users \ [user name] \ AppData \ Local \ [ (Project Name) or (AssemblyCompany) ] \ [name project_cashBuild] \ [AssemblyVersion] \ user.config

Для начала нам нужно создать такие переменные для Properties.Settings. Перейдем в Properties -> Settings.settings:



Я создал 3-и переменные и выбрал область их использования: 2- область пользователь и 1- приложение.

Различие между областями просты. Область приложения можно только читать, а пользователь — изменять и читать.

Вернемся к переменным:

  • Version — версия нашей программы. Определил ее строкой и областью приложение. Т.к. версия может содержать буквы (например, b — от beta). А область выбрал, чтоб не менялась наша версия приложения (т.к. AssemblyVersion редко кто использует).
  • Save_text — это переменная, куда мы будем сохранять наш текст.
  • open_sum — сколько раз мы открыли программу.

Результаты работы программы

Первый запуск, мы видим, что кол-во запусков равно 1. И теста в richTextBox1 нет.


Теперь напишем и сохраним текст.


При втором запуске мы видим, что текст сохранен, и кол-во запусков уже 2-ва.


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

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

Теперь перейдем к нашей теме. Для работы с таким типом файлов, нам нужно создать класс по работе с ним. Создаем класс, например «IniFile», подключаем пространство имен, которых нет:


А теперь разбираем по-порядку:

Теперь переходим в основную программу.

Результаты работы программы

При первом запуска, у нас нет файла config.ini. Поэтому при проверке возвращаются fasle и мы приравниваем окно к минимальным параметрам.


Меняем параметры окна и жмем «Применить»


Редактируем файл config.ini руками и жмем загрузить.


На этом все, в следующий раз опишу работу с xml файлами и с бинарными файлами.

Я - новый программист Windows, и я не уверен, где я должен хранить настраиваемые пользователем параметры приложения. Я понимаю необходимость предоставления пользователю удобных средств для изменения настроек приложения, таких как Редактирование | Форма настроек или аналогичная. Но где я должен хранить значения после того, как пользователь нажмет кнопку "Применить" в этой форме?

Каковы плюсы и минусы хранения настроек в реестре Windows по сравнению с хранением их в локальном INI-файле, конфигурационном файле или аналогичном?

Плюсы конфигурационного файла:

  1. Легко сделать. Не нужно знать никаких вызовов Windows API. Вам просто нужно знать интерфейс ввода / вывода файлов вашего языка программирования.
  2. Портативный. Если вы портируете свое приложение на другую ОС, вам не нужно менять формат настроек.
  3. Пользователь редактируемый. Пользователь может редактировать конфигурационный файл вне выполняемой программы.

Плюсы реестра:

  1. Secure. Пользователь не может случайно удалить файл конфигурации или повредить данные, если он / она не знает о regedit. И тогда пользователь просто напрашивается на неприятности.
  2. Я не опытный программист Windows, но я уверен, что использование реестра облегчает выполнение других специфических для Windows вещей (пользовательских настроек, настроек сетевого администрирования, таких как групповая политика или что-то еще).

Если вам нужен простой способ хранения информации о конфигурации, я бы порекомендовал файл конфигурации, используя INI или XML в качестве формата. Я предлагаю использовать реестр только в том случае, если вы хотите использовать что-то конкретное из реестра.

У Джеффа Этвуда есть отличная статья о реестре Windows и о том, почему лучше использовать файлы.INI.

Моя жизнь была бы намного проще, если бы настройки для каждого приложения были сохранены в месте, где я мог бы легко их видеть, манипулировать ими и создавать резервные копии. Мол, скажем. в файлах INI.

  • Реестр является единственной точкой отказа. Вот почему каждый совет по редактированию реестра, который вы когда-либо найдете, начинается с огромного кричащего заявления об отказе от того, как вы можете сломать свой компьютер с помощью regedit.
  • Реестр непрозрачный и двоичный. Как бы мне не нравился налог на угловые скобки, по крайней мере, XML-файлы конфигурации достаточно понятны для человека, и они позволяют столько комментариев, сколько вы считаете нужным.
  • Реестр должен быть синхронизирован с файловой системой. Удалите приложение, не "удаляя" его, и вы останетесь с устаревшей регистрацией. Или если приложение имеет плохо написанный деинсталлятор. Файловая система больше не является оператором записи - она ​​должна как-то синхронизироваться с реестром. Это полное нарушение принципа СУХОЙ.
  • Реестр монолитный. Допустим, вы хотите переместить приложение по другому пути на вашей машине или даже на другую машину в целом. Удачи в извлечении соответствующих настроек для этого конкретного приложения из гигантского архива реестра. У определенного приложения обычно есть десятки параметров, разбросанных по всему реестру.

Согласно документации для GetPrivateProfileString, вы должны использовать реестр для хранения информации об инициализации.

Однако, так сказать, если вы все еще хотите использовать файлы.ini и использовать стандартные API профиля ( GetPrivateProfileString , WritePrivateProfileString и тому подобное) для доступа к ним они предоставляют встроенные способы автоматического предоставления "виртуальных файлов.ini", поддерживаемых реестром. Беспроигрышная!

Здесь есть похожий вопрос, который охватывает некоторые плюсы и минусы.

Использование ini-файла в том же каталоге, что и приложение, позволяет создавать резервные копии его вместе с приложением. Поэтому после перезагрузки ОС вы просто восстанавливаете каталог приложения и получаете свою конфигурацию так, как вам этого хочется.

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

Есть еще одно преимущество использования INI-файла перед реестром, о котором я не упоминал: если пользователь использует какое-либо шифрование на основе тома / файла, он может довольно легко зашифровать INI-файл. С реестром это, вероятно, будет более проблематичным.

Существующие ответы охватывают много вопросов, но я подумал, что упомяну еще один момент.

Я использую реестр для хранения общесистемных настроек. То есть, когда 2 или более программ нуждаются в одинаковых настройках. Другими словами, настройка используется несколькими программами.

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

Зачем ставить общесистемные настройки в реестр? Ну, я обнаружил, что если настройка является общей, но вы используете локальные файлы конфигурации, вы в конечном итоге дублируете настройки. Это может означать, что вам в конечном итоге потребуется изменить настройку в нескольких местах.

Например, скажем, программа A и программа B указывают на одну и ту же базу данных. У вас может быть "общесистемный" параметр реестра для строки подключения. Если вы хотите указать на другую базу данных, вы можете изменить строку подключения в одном месте, и обе программы теперь будут работать с другой базой данных.

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

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

Стандартные механизмы сохранения пользовательских данных ("настроек") имеют недостатки:

1. Работают только на компьютере пользователя (т.к. хранятся в папке пользователя, а не в базе)

2. Настройки теряются при динамическом обновлении или смене компьютера

в 8.2 эта проблема решена механизмом платформы

для 8.1 используются встроенные в типовые конфигурации механизмы хранения (регистр сведений "СохраненныеНастройки") для создания более универсальных функций сохранения настроек и сохранения универсальности приходится проверять, какие методы доступны и использовать оптимальные (код ниже)

Интерфейсы использования функций такие же, как и у СохранитьЗначение/ВосстановитьЗначение принцип действия прост, если доступны методы сохранения типовых конфигураций 1С используются они иначе платформенные

Фунции гл_ВосстановитьЗначение; гл_СохранитьЗначение - замена СохранитьЗначение;ВосстановитьЗначение, ТекущийПользовательВСправочникеПользователи; НеДоступныМеханизмыСохраненияНастроекВКонфигурации - вспомогательные

Процедура гл_СохранитьЗначение ( ИмяНастройки , ЗначениеНастройки ) Экспорт

Если НедоступныМеханизмыСохраненияНастроекВКонфигурации () Тогда
СохранитьЗначение ( ИмяНастройки , ЗначениеНастройки );
Иначе
НаименованиеНастройки = "Основная" ;
ТекПользовательВСправочнике = ТекущийПользовательВСправочникеПользователи ();

НаборЗаписей = РегистрыСведений . СохраненныеНастройки . СоздатьНаборЗаписей ();

//Установка отборов
НаборЗаписей . Отбор . Пользователь . Установить ( ТекПользовательВСправочнике );
НаборЗаписей . Отбор . ИмяОбъекта . Установить ( ИмяНастройки );

//Добавление записи настройки в регистр
НоваяЗапись = НаборЗаписей . Добавить ();
НоваяЗапись . ИмяОбъекта = ИмяНастройки ;
НоваяЗапись . Пользователь = ТекПользовательВСправочнике ;
НоваяЗапись . СохраненнаяНастройка = Новый ХранилищеЗначения ( ЗначениеНастройки );
НоваяЗапись . НаименованиеНастройки = НаименованиеНастройки ;
НаборЗаписей . Записать ();
КонецЕсли;

Функция гл_ВосстановитьЗначение ( ИмяНастройки ) Экспорт

Если НедоступныМеханизмыСохраненияНастроекВКонфигурации () Тогда
Возврат ВосстановитьЗначение ( ИмяНастройки );
Иначе
Запрос = Новый Запрос ( "ВЫБРАТЬ ПЕРВЫЕ 1
| СохраненныеНастройки.СохраненнаяНастройка
|ИЗ
| РегистрСведений.СохраненныеНастройки КАК СохраненныеНастройки
|ГДЕ
| СохраненныеНастройки.Пользователь = &Пользователь
| И СохраненныеНастройки.ИмяОбъекта = &ИмяОбъекта
| И СохраненныеНастройки.НаименованиеНастройки = ""Основная""" );
Запрос . УстановитьПараметр ( "Пользователь" , ТекущийПользовательВСправочникеПользователи ());
Запрос . УстановитьПараметр ( "ИмяОбъекта" , ИмяНастройки );
Результат = Запрос . Выполнить ();

Если Результат . Пустой () Тогда
Возврат Неопределено;
Иначе
СохраненноеЗначениеХранилище = Результат . Выгрузить ()[ 0 ]. СохраненнаяНастройка ;
Возврат СохраненноеЗначениеХранилище . Получить ();
КонецЕсли;
КонецЕсли;

ТекущийПользователь = ПользователиИнформационнойБазы . ТекущийПользователь ();
ИмяТекущегоПользователя = ? ( ПустаяСтрока ( ТекущийПользователь ), "НеАвторизован" , ТекущийПользователь );

Возврат Справочники . Пользователи . НайтиПоКоду ( ИмяТекущегоПользователя );

//Для доступности сохранения в конфигурация. должны присутствовать регистр сведений СохраненныеНастройки и справочник Пользователи
Возврат ( Метаданные . РегистрыСведений . Найти ( "СохраненныеНастройки" ) = Неопределено ИЛИ
Метаданные . Справочники . Найти ( "Пользователи" ) = Неопределено);

Читайте также: