как ограничить список выбора 1с управляемые формы

Установка отбора для поля ввода управляемой формы через ПараметрыВыбора (без переопределения событий «НачалоВыбора», «Автоподбор»)

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

Данное свойство представляет собой фиксированный массив элементов типа «ПараметрВыбора», позволяет организовать простую фильтрацию доступных для выбора элементов в поле ввода. При этом фильтрация будет работать как при автоподборе, так и при открытии формы выбора.

Рассмотрим пару типовых случаев применения этого свойства для установки отбора:

Отфильтруем ввод сотрудника по значению реквизита «Организация» на форме документа.

Фильтрация будет установлена у поля ввода «СписокСотрудниковСотрудник», в таблице документа.
Для выбора будут доступны только те сотрудники, у которых значения реквизита «Организация» совпадает со значением, установленным в реквизите «Организация» документа.

Вот так будет выглядеть процедура установки фильтра:

Данная процедура вызывается в событии формы «ПриОткрытии» и в событии «ПриИзменении» поля ввода «Организация».

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

Фильтрация будет установлена у поля ввода «Статус».

Если у сохранённого документа установлен статус «Черновик», то список доступных элементов перечисления «Статусы» будет ограничен значениями «Черновик» и «НаРассмотрении».

Данная процедура вызывается в событиях формы «ПриСозданииНаСервере» и «ПослеЗаписиНаСервере»

Кроме этого в параметрах выбора можно устанавливать свои нетиповые свойства:

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

Источник

Как ограничить выбор элемента справочника одной группой при клавиатурном вводе

Для поля формы создал событие НачалоВыбора.
Процедура ограничивает возможность выбора элемента справочника по родителю.

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

Подскажите пути решения. Заранее спасибо.

Здравствуйте!
В обработчик события «ИмяПоляОкончаниеВводаТекста» Можно добавить отбор :
МассивОтбора = Новый Массив();

ПараметрВыбораДляВида1 = Новый ПараметрВыбора(«Отбор.ПометкаУдаления»,Ложь);
ПараметрВыбораДляВида2 = Новый ПараметрВыбора(«Отбор.Родитель»,ИмяРодителя);

ФиксированныйМассивОтбора = Новый ФиксированныйМассив(МассивОтбора) ;

(3) Agapov_Stas, (4) soleil, именно для удобства ввода я и включил возможность редактирования текста.

ДокументМенеджер. (DocumentManager. )
ОбработкаПолученияДанныхВыбора (ChoiceDataGetProcessing)
Синтаксис:

Возникает на сервере перед стандартным формированием списка при вводе по строке, автоподборе текста и быстром выборе, а также при выполнении метода

(11) Agapov_Stas, Аргументируйте ОбработкаПолученияДанныхВыбора это обработка модуляМенеджера срабатывает при изменении поля выбора на форме

Тип: СписокЗначений.
В обработчике можно сформировать и передать в этом параметре данные для выбора. При этом параметр должен быть установлен в Ложь.

Для программного формирования списка выбора необходимо переопределить обработчик события
ОбработкаПолученияДанныхВыбора менеджера объекта. В обработчик передается набор параметров,
определяющих условия формирования списка выбора.
Набор параметров представляет собой структуру, которая содержит:
· строку поиска — текстовую строку, которая содержит текст, который пользователь ввел в поле ввода. Данный
параметр присутствует всегда.
· отбор — структура, которая описывает отбор так, как его описывает параметр формы Отбор для расширения
формы для динамического списка. Данный параметр присутствует всегда.
· свойство, которое указывает режим выбора групп и элементов (передается только для иерархических списков).
· кроме этого, в структуре передаются элементы, которые заданы в свойствах элемента формы Связи параметров
выбора и Параметры выбора.
Кроме того, в обработчик передается переменная, в которую следует вернуть сформированный список выбора и
флаг стандартной обработки, который определяет поведение системы после того, как произойдет выход из
обработчика.
Если разработчик устанавливает флаг стандартной обработки в состояние Ложь, то ему необходимо самому
полностью формировать список выбора (учитывая ограничение в 50 отображаемых элементов).
Если флаг стандартной обработки установить в значение Истина, то можно представить системе возможность
сформировать список выбора, но при этом можно модифицировать параметры выбора (добавить дополнительные
значения отбора, изменить режим выбора групп и элементов и т.д.).

Источник

Как ограничить поля отбора в динамическом списке и ничего не сломать

Однако, долгое время разработчики не имели возможность запрещать пользователям делать отборы по конкретным полям и их реквизитам. Такое бывает необходимо, чтобы не дать возможность «положить» списки со сложными запросами или с большим количеством данных.

И вот с версии 8.3.10 в платформе появился метод УстановитьОграниченияИспользованияВОтборе()

Тип: Массив.
Пути к полям компоновки, на которые требуется установить ограничение.

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

Использование в версии:

Доступен, начиная с версии 8.3.10.

Здесь нас интересует этот пункт:

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

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

Приведём такой пример. Есть динамический список с документами. Необходимо запретить пользователям делать фильтры по полям, если в шапке формы пустой параметр «Организация». Возьмём для нашего эксперимента форму журнала документов продажи из демо базы ERP 2.4:

Для этого добавим форму в расширение:

Подключимся к обработчику изменения организации:

И вставим такой простой код:

Обновим базу и откроем форму в режиме предприятия. Сразу видим, что в контекстном меню по полю «Подразделение» нет возможности поиска:

Расширенный поиск не позволяет выбирать подразделение:

Так же отбор недоступен и в форме настройки списка:

А теперь заполним организацию:

И появилась возможность фильтровать в расширенном поиске:

Ну и настройка динамического списка заработала:

А значит теперь мы можем наложить отбор на подразделение. Давайте так и сделаем.

Сейчас в списке доступны три строки с двумя подразделениями:

Установим отбор по подразделению «Дирекция» при помощи Ctrl+Alt+F

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

Странно, да? Отбор отключился. Но надпись осталась. Да, её не трудно закрыть крестиком вручную, но пользователю будет непонятно, почему показан отбор, который не работает.

Для начала снова выберем организацию в шапке формы и установим отбор по подразделению:

Хорошо, а теперь очистим организацию в шапке:

Мы установили ограничение на отбор, но существующий при этом не сбросился. А в настройке списка наш отбор помечен красным и более недоступен:

Как же так? Понять это поможет другая статья, в которой рассказывается принцип того, как СКД (на которой и базируются динамические списки) работает с ограничениями полей:
Ограничения полей, или как обмануть СКД?.
Прочитав её, станет понятно, что ограничения полей в отборах полноценно влияют только на пользовательскую доступность полей, но не на логику выборки данных. То есть, пользовательские настройки обходят ограничения полей.

Интересно, что решение, которое было предложено в статье, в данной ситуации не работает. Если использовать КомпоновщикНастроек.Восстановить(), то пользовательские отборы всё равно остаются на месте.

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

Теперь когда пользователь очищает поле «Организация», то и наш «неправильный» отбор отключается.

Можно заметить, что при этом поле остаётся. И самое интересное, что если пользователь вручную нажмёт его использование, то и, несмотря на ограничения отборов, фильтрация применится:

Но что же делать? Придётся не отключать использование отбора, а просто удалять его.

Теперь при очистке организации, так же удаляются и «запрещенные» отборы:

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

Хорошо, мы разобрались с ограничениями отборов в динамическом списке. Но как обстоят дела с другими ограничениями? Добавим запреты на группировку и сортировку:

Открываем форму с пустой организацией и видим, что подразделения нет в доступных к группировке полей. Всё хорошо.

Теперь выберем организацию и добавим группировку:

Всё хорошо применилось:

А теперь очистим организацию. После очистки, наш код запрещает использование поля Подразделение в группировках.

И вот мы видим такую ошибку:

На группировку 1С поругалась. И форма теперь показывает пустой список:

То же самое и с ограничением по сортировке.

Выходит, что платформа позволяет блокировать такие действия. Но с отборами это не работает. Хорошо, что мы написали свой метод по обработке этого?

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

Если изначально форма списка не содержала ограничения по отборам, то при внесении изменений, у пользователей могут остаться сохранённые настройки. Как и те, что подгружаются автоматически при открытии формы, так и те, что пользователь может подгрузить вручную по кнопке «Выбрать настройки».

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

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

Для этого в форме с пустой организацией зайдём в «Настроить список». Как видим, поля суммы в отборах нет:

И перенесем доступные к сортировке поля в группу с отборами:

Фильтр применился. Несмотря на ограничения.

Да, этот способ обхода замудрён, но работает. И к сожалению, события по изменению отборов в 1С нет.

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

Выводы:

Ограничения отборов в динамическом списке автоматически обрабатываются недостаточно, поэтому:

1. Дополнительно программно обходите настройки

а) при установки ограничений

б) при загрузке пользовательских настроек

2. Если запрещаете отборы, то запрещайте и группировку\сортировку.

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

Понравилась статья?

Подайте знак автору =) Поставьте плюс, оставляйте комментарий и переходите к другим публикациям:

Источник

Ваш браузер устарел, пожалуйста обновите ваш браузер пройдя по ссылке www.microsoft.com/download

ОГЛАВЛЕНИЕ

ВВЕДЕНИЕ

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

СВЯЗИ ПАРАМЕТРОВ ВЫБОРА

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

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

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

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

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

ПАРАМЕТРЫ ВЫБОРА

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

Платформа накладывает следующие ограничения на создание выражений условий связей параметров. Имя параметра должно удовлетворять условиям написания имен (не содержать пробелов, начинаться может с буквы или символа подчеркивание); в имени можно использовать только одну точку или не использовать точку вообще. Значение параметра должно быть значением реквизита формы без использования подчиненных реквизитов, однако можно указать реквизит табличной части в специальном формате через элементы формы: Элементы.Список.ТекущиеДанные.ИмяРеквизита.

ОБХОД ОГРАНИЧЕНИЙ ПАРАМЕТРОВ ВЫБОРА

Практика

На практике мне попадались следующие решения:

Недостатками этих решений являются:

Решение

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

Аналогично для второго примера условие связи будет: Отбор.Договор = Договор. Несмотря на то, что условие накладывается на справочник Статьи, в котором отсутствует поле Договор, такое условие в рамках платформы вполне допустимо использовать. В этом случае в форму выбора будет передан параметр Договор со значением из реквизита формы Договор. Далее нам необходимо построить запрос через соединение основной таблицы Статьи с таблицей РегистрСведений.СтатьиДоговора и уже на поле регистра сведений наложить условие отбора по переданному значению договора.

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

ПОДСИСТЕМА РАБОТА С ДАННЫМИ ВЫБОРА

Рисунок 1. Диаграмма последовательности

Предлагаемая подсистема реализует интерфейс для работы следующих сценариев:

Подключение к подсистеме производится через вставку вызова в форме выбора и добавление предопределенной процедуры менеджера объекта ОбработкаПолученияДанныхВыбора.

Обработка параметров, функция ПолучитьТекстЗапроса

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

В следующем листинге демонстрируется пример-заготовка реализации такой функции. Данная реализация основана на использовании объектной модели запроса. Работа с объектной моделью осуществляется с использованием подсистемы «Работа со схемой запроса». С шаблонами построения текста запроса при использовании подсистемы можно подробнее ознакомиться в одноименной статье.

Листинг 1. Общая структура функции ПолучитьТекстЗапроса на примере справочника _ДемоНоменклатура

Динамический список формы выбора

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

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

Для работа подсистемы необходимо настроить динамический список формы выбора: установить произвольный запрос и изменить псевдоним основной таблицы на имя «Источник».

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

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

Листинг 2. Демонстрация разделения параметров в функции ПолучитьТекстЗапроса

Листинг 3. Подключение формы выбора к подсистеме

Примечание: подключаемая форма выбора должна содержать произвольный текст запроса основной таблицы, при этом псевдоним основной таблицы должен быть предопределенным «Источник». Этот же псевдоним используется в подсистеме для построения текста запроса путем добавления условия и соединений.

Список данных выбора

Рисунок 2. Список выбора

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

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

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

Листинг 4. Подключение процедуры к подсистеме

Проверка на соответствие условиям параметров выбора. Заполнение по-умолчанию.

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

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

Листинг 5. Проверка соответствия переменной СсылкаНаЗначение переданным параметрам выбора из структуры Параметры

СТЕНД «РАБОТА С ДАННЫМИ ВЫБОРА»

Рисунок 3. Форма обработки стенда

Для демонстрации работы подсистемы выбран справочник _ДемоНоменклатура из демо-конфигурации БСП. С помощью расширения конфигурации в справочнике доработан менеджер объекта и форма выбора. В модуль менеджера добавлена функция ПолучитьТекстЗапроса и предопределенная процедура ОбработкаДанныхВыбора. В форме выбора добавлен вызов процедуры ЗаполнитьТекстЗапросаДинамическогоСписка.

В функции ПолучитьТекстЗапроса реализована обработка дополнительных параметров:

В процедуре используются приемы по формированию текста запроса в объектной модели с использованием подсистемы РаботаСоСхемойЗапроса. Более подробно читайте здесь.

Источник