Как определить, из какой формы вызвана команда 1С: список или объект?

← На главную

При разработке управляемых приложений в 1С часто возникает задача: выполнить определенную логику команды по-разному, в зависимости от того, где она была нажата — в ФормеСписка или в ФормеОбъекта. Многие начинающие разработчики пытаются идти путем «парсинга» имени формы или использования блока Попытка для проверки наличия реквизита Объект. Давайте разберем, почему такие методы ненадежны и какой подход является профессиональным стандартом.

Почему не стоит анализировать реквизиты или имена форм?

Использование конструкции Попытка для доступа к реквизиту Объект — это путь к ошибкам. Во-первых, реквизит может быть переименован или отсутствовать в конкретной форме. Во-вторых, даже если форма объекта открыта, в ней не всегда есть стандартный реквизит Объект с таким же именем. Парсинг имен форм также считается «плохим тоном», так как конфигурация может содержать сотни форм с произвольными именами, и ваша логика сломается при первой же правке метаданных.

Решение через анализ параметров выполнения команды

Самый надежный и архитектурно верный способ — это использование контекста, который платформа 1С передает в обработчик команды через ПараметрыВыполненияКоманды. Когда вы вызываете команду, платформа автоматически заполняет этот параметр, предоставляя доступ к источнику вызова.

Рассмотрим, как это работает на практике. У каждой формы есть свои уникальные признаки, которые можно проверить через источник команды:

У ФормыОбъекта (или формы записи) всегда присутствует Ключ — это ссылка на конкретный объект, с которым ведется работа.
У ФормыСписка обычно присутствует параметр РежимВыбора, если форма была открыта для подбора элементов.

Разберем пример реализации проверки в модуле команды:


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

Рекомендуемый подход: разделение команд

Хотя анализ параметров позволяет различить источник, профессионалы рекомендуют придерживаться принципа разделения ответственности. Если логика работы в списке и в объекте сильно отличается, лучше создать две разные команды:

Одну команду привязать к типу ДанныеФормыСтруктура (для формы объекта).
Другую — к ДинамическийСписок (для формы списка).

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

Заключение

Мы выяснили, что попытки «угадать» форму через Попытка — это ненадежный путь. Вместо этого используйте:

Анализ свойства Источник из ПараметрыВыполненияКоманды, чтобы проверить наличие специфических параметров формы, таких как Ключ.
Разделение команд в конфигураторе, чтобы платформа сама ограничивала контекст вызова.

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

← На главную