Как программно проверить тип и значение режима совместимости в 1С

← На главную

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

Определение типа через метаданные конфигурации

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


// Самый надежный способ получения типа для сравнения
ТипРежима = ТипЗнч(Метаданные.РежимСовместимости);

Если ТипЗнч(ПеременнаяРежим) = ТипРежима Тогда
    // Код для обработки режима совместимости
КонецЕсли;

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

Использование строкового имени типа

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

Для проверки типа режима совместимости достаточно следующей конструкции:


Если ТипЗнч(ПеременнаяРежим) = Тип("РежимСовместимости") Тогда
    // Ваша логика здесь
КонецЕсли;

Это стандартный и рекомендуемый способ обращения к системному перечислению. Он избавляет код от лишних обращений к дереву метаданных и делает его максимально прозрачным для других разработчиков.

Низкоуровневый метод: использование внутреннего GUID

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

Каждый системный тип в 1С имеет свой уникальный GUID. Для типа РежимСовместимости этот идентификатор — 881683fb-79f6-4ce9-be9d-a777275ea39f. Проанализируем пример использования этого знания:


// Использование внутреннего идентификатора типа
ТипРежимСовместимости = ЗначениеИзСтрокиВнутр("{""T"",881683fb-79f6-4ce9-be9d-a777275ea39f}");

Если ТипЗнч(Режим) = ТипРежимСовместимости Тогда
    // Код сработает, но такой подход считается плохой практикой
КонецЕсли;

Важно: Несмотря на работоспособность, использовать данный метод в промышленной разработке не рекомендуется. Это "магические строки" (hardcode), которые снижают читаемость кода и могут теоретически измениться в будущих глобальных обновлениях платформы, хотя типы системных перечислений обычно стабильны.

Проверка конкретных значений режима совместимости

Зачастую программисту мало знать тип переменной, важно понимать, какая именно версия платформы эмулируется. Для этого мы должны сравнивать значение со значениями системного перечисления РежимСовместимости. Посмотрим на пример реализации логики в зависимости от версии:


Если Метаданные.РежимСовместимости = РежимСовместимости.Версия8_3_21 Тогда
    // Используем возможности, появившиеся в 8.3.21
ИначеЕсли Метаданные.РежимСовместимости = РежимСовместимости.НеИспользовать Тогда
    // Логика для самой актуальной версии без обратной совместимости
КонецЕсли;

Список доступных значений в РежимСовместимости динамически расширяется платформой. При написании кода учитывайте, что отсутствие режима совместимости (значение НеИспользовать) накладывает самые жесткие требования на качество кода (например, запрет модальных окон).

Режим совместимости интерфейса и расширений

Рассмотрим дополнительные аспекты, которые часто упускаются из виду:

Режим совместимости интерфейса. Существует отдельное свойство РежимСовместимостиИнтерфейса. Оно определяет визуальное поведение форм. Его тип проверяется аналогично: Тип("РежимСовместимостиИнтерфейса").
Расширения конфигурации. Если вы пишете код внутри расширения, помните, что у расширения есть свой собственный режим совместимости. Для его проверки используйте ЭтотОбъект.Метаданные().РежимСовместимости. Несоответствие режимов расширения и основной конфигурации может привести к трудноотлавливаемым ошибкам.

Использование инструментов БСП (Библиотеки стандартных подсистем)

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

Рекомендуется использовать функцию ПоддерживаетсяРежимСовместимости из общего модуля ОбщегоНазначения:


// Проверка, поддерживает ли конфигурация возможности версии 8.3.16
Если ОбщегоНазначения.ПоддерживаетсяРежимСовместимости("8.3.16") Тогда
    // Безопасное использование новых функций
КонецЕсли;

Этот метод инкапсулирует в себе все проверки и делает код устойчивым к изменениям в структуре метаданных или именовании версий платформой.

Заключение

Подводя итог, можно выделить следующую иерархию методов проверки (от лучшего к худшему):

Методы БСП: самый безопасный и современный вариант.
Сравнение через Тип("РежимСовместимости"): стандарт платформы.
Сравнение с ТипЗнч(Метаданные.РежимСовместимости): надежный классический способ.
Использование GUID через ЗначениеИзСтрокиВнутр: только для исследовательских целей.

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