1с динамический список сбросить настройки
1. Если текст запроса динамического списка переопределяется в коде, то рекомендуется придерживаться правил, описанных ниже. Это нужно для того, чтобы:
- разработчики, глядя на запрос в динамическом списке, могли однозначно понять, что он переопределяется в коде конфигурации;
- не снижать производительность при открытии формы, установке текста запроса, основной таблицы и признака динамического считывания данных.
1.1. В редакторе запроса динамического списка следует устанавливать полноценный наиболее часто выполняемый текст запроса (запрос по умолчанию), чтобы при открытии формы, в большинстве случаев, не происходила программная установка текста запроса, снижающая производительность. Исключением является случай, когда текст запроса собирается программно.
ВЫБРАТЬ
НоменклатураПереопределяемый.Ссылка КАК Ссылка
ИЗ
Справочник.Номенклатура КАК НоменклатураПереопределяемый
Запрос, требующий обязательной замены в коде конфигурации, т.к. не содержит секции ИЗ:
ВЫБРАТЬ
ЗНАЧЕНИЕ(Справочник.Номенклатура.ПустаяСсылка) КАК Ссылка
1.2. Псевдонимы таблиц должны заканчиваться постфиксом «Переопределяемый», чтобы визуально было заметно, что этот запрос может переопределяться в коде конфигурации.
ВЫБРАТЬ
Номенклатура Переопределяемый .Ссылка КАК Ссылка
ИЗ
Справочник.Номенклатура КАК Номенклатура Переопределяемый
ВЫБРАТЬ
Номенклатура.Ссылка КАК Ссылка
ИЗ
Справочник.Номенклатура КАК Номенклатура
1.3. Установка текста запроса и основной таблицы при первичной инициализации динамического списка (в ПриСозданииНаСервере) должна выполняться до любого обращения к настройкам этого списка (в т.ч. параметрам), чтобы не снижалась производительность. В остальных случаях, если требуется изменить текст запроса и основную таблицу, между этими действиями не следует обращаться к настройкам (можно до них или после). При наличии БСП, следует использовать процедуру ОбщегоНазначения.УстановитьСвойстваДинамическогоСписка(). Это необходимо для повышения производительности и возможности автоматического сбора переопределяемых текстов запросов динамических списков.
СвойстваСписка = ОбщегоНазначения.СтруктураСвойствДинамическогоСписка();
СвойстваСписка.ОсновнаяТаблица = "Справочник.Номенклатура";
СвойстваСписка.ДинамическоеСчитываниеДанных = Истина;
СвойстваСписка.ТекстЗапроса = ТекстЗапроса;
ОбщегоНазначения.УстановитьСвойстваДинамическогоСписка(Элементы.Список,
СвойстваСписка);
Список.Параметры.УстановитьЗначениеПараметра("Параметр1", 42);
Список.ТекстЗапроса = ТекстЗапроса;
Список.Параметры.УстановитьЗначениеПараметра("Параметр1", 42);
Список.ОсновнаяТаблица = ОсновнаяТаблица;
В этом случае снижается производительность из-за того, что при изменении текста запроса или основной таблицы сбрасывается источник доступных настроек и при обращении к Список.Параметры источник инициализируется заново.
2. Переопределяемые тексты запросов динамического списка можно размещать в любых модулях конфигурации, но следует следить за тем, чтобы текст запроса в динамическом списке был точно таким же, как и переопределяемый текст запроса по умолчанию (наиболее часто используемый).
Задача состояла в следующем. В форме динамического списка необходимо было показать итоговую информацию. К примеру, в журнале накладных вывести количество накладных и общую сумму. Получить необходимые данные не составляло труда - формировался запрос с условием, соответствующим текущему отбору списка и запускался на выполнение. Но неожиданно проблемой оказалось обеспечение "синхронности" между данными списка и итоговой информацией.
То есть, данные динамического списка могут изменяться по различным причинам:
1. Изменился отбор списка
2. Пользователь в текущем сеансе изменил или удалил объект из списка
3. Пользователь нажал в форме кнопку "Обновить" (либо настроено автоматическое обновление списка)
Соответственно, хотелось бы после каждого такого события сразу пересчитывать служебную информацию.
Варианты решения были следующие:
1. Использовать событие формы "ОбновлениеОтображения".
Это событие действительно реагирует на любое изменение динамического списка. Но оно также вызывается и во многих других случаях. В частности, при смене страницы формы, при активизации строки в списке (если назначена обработка этих событий) и т.д. Короче, использование этого варианта вызывало приличные тормоза из-за перерасчета итогов после каждого чиха пользователя.
2. Использовать событие табличного поля "ПриПолученииДанных".
Вариант имеет такие же недостатки, как и предыдущий, хотя и в меньшей степени. Т.е. событие (а значит, и перерасчет итогов) выполнялось не только когда данные списка действительно менялись, но и при прокрутке списка, и даже при изменении размеров формы.
3. Добавить в форму кнопочку "Рассчитать", чтобы пользователь жал на неё всякий раз, когда ему потребуются актуальные итоги по списку. Коряво, неудобно, но приходилось поступать именно так, пока не появился ВАРИАНТ 4.
Хотя решение немного через .опу
Суть: на форму добавляется скрытое табличное поле, источником данных которого служит нужный нам динамический список, и далее используется событие "ПриПолученииДанных" этого табличного поля. Так как данное табличное поле не прокручивается и не меняет размеров, то событие возникает только тогда, когда список реально требует обновления.
Правда, в процессе реализации этого варианта вылезло ещё несколько "особенностей" платформы, но почти все удалось обойти.
В результате, сервисный код упрятан в две процедуры общего модуля: ПодключитьОбработчикОбновленияСписка(. ) и ОтключитьОбработчикОбновленияСписка(. ). Первая назначает для обработки обновления списка процедуру модуля формы, вторая, соответственно, отключает обработчик. Выглядит всё это так:
Теперь ложка дёгтя.
Алгоритм не отрабатывает ситуацию, когда список полностью очищается. То есть, в списке были какие-то строки, а потом пользователь все строки удалил, либо задал такой отбор, при котором в список не попадает ни один объект. Как оказалось, 1С просто не вызывает событие "ПриПолученииДанных" для пустого списка.
Чтобы обойти эту проблему, пришлось погрузиться в .опу уже по локоть.
Используя событие "ПриАктивизацииСтроки" нашего вспомогательного табличного поля, можно отловить ситуацию, когда свойство ТекущаяСтрока табличного поля меняет значение на Неопределено, сигнализируя, что в списке больше нет ни одной строки. Но очередной сюрприз от платформы - приняв значение Неопределено, ТекущаяСтрока "фиксируется" на нем, и не меняется, даже когда в списке вновь появляются объекты. То есть, если не поменять значение текущей строки, второй раз событие "ПриАктивизацииСтроки" уже не сработает.
Трагедия в том, что узнать, что список вновь заполнен, можно только в "ПриПолученииДанных", а изменить текущую строку во время обработки данного события невозможно - 1С вылетает с критической ошибкой (желающие могут попробовать). Помогли только пляски с шаманским бубном вокруг компьютера.
В итоге, получилось следующее:
Замечание от Гений1С:
Можно попробовать подключить функцию изменения данных ПодключитьОбработчикИзмененияДанных на данные списка.
Замечание от clappa:
Мне удалось использовать ПодключитьОбработчикИзмененияДанных только для контроля за изменением отбора динамического списка. В других перечисленных случаях этот метод бесполезен. В частности, изменение порядка он "не ловит".
Итак, если хотите узнать, почему в 1С:БП не получается открыть встроенный отчет как внешний, есть ли смысл задавать настройки компоновки для динамического списка и при каких условиях нужно индексировать временные таблицы, то ознакомьтесь с сегодняшней подборкой. Приятного прочтения!
Вопрос №1: Есть ли смысл использовать настройки компоновки для динамического списка?
Ответ
- Да, запрос, который извлекает из базы данные динамического списка, тоже может изменяться в зависимости от используемых настроек компоновки.
В одном из занятий курса по СКД мы рассматриваем, как получить исполняемые настройки компоновки для динамического списка.
Например, в типовой конфигурации 1С:БП в форме списка справочника “Контрагенты” используется динамический список с запросом:
Видно, что в тексте запроса есть конструкции в фигурных скобках. Значит, таблицы регистров будут применяться в запросах, если поля из них используются в настройках компоновки.
Это пример разобранного вопроса из Мастер-группы курсаПрофессиональная разработка отчетов в 1С 8.3 на СКД .
Вопрос №2: При каких условиях необходимо индексировать временные таблицы?
Хотел бы задать вопрос про индексирование временных таблиц. Рекомендуется индексировать те поля, которые участвуют в условиях отбора или условиях соединения, но в тоже время нельзя бездумно использовать индекс. В связи с этим вопрос: при каком примерном количестве строк нужно индексировать ВТ (временная таблица)? Имеет ли смысл индексировать, если в ВТ будет до 100 строк? Где-то попадалась рекомендация, что нужно индексировать при наличии от 1000 строк.Ответ
Этот вопрос рассмотрен в статье на нашем сайте – 3 главных вопроса про временные таблицы 1С.
В общем случае рекомендацию можно сформулировать следующим образом – индексирование временной таблицы нужно использовать тогда, когда это дает эффект. Если же индекс не будет использоваться СУБД или наоборот – на индексирование будет потрачено дополнительное время, то индексирование таблицы будет неэффективно. Способ проверки, будет ли использоваться индекс в конкретной ситуации, также приведен в указанной статье.
Это пример разобранного вопроса из Мастер-группы курсаРазработка и оптимизация запросов в 1С:Предприятие 8.3 .
Вопрос №3: Почему сохраненный типовой отчет 1C:БП не открывается как внешний?
Ответ
Причина ошибки заключается в том, что у внешнего отчета или обработки в принципе нет модуля менеджера. А у отчета или обработки из конфигурации такой модуль присутствует.
В 1С:БП в модуле менеджера отчетов есть программный код, а в 1C:УТ – нет. Этим объясняется разница в поведении конфигураций.
При сохранении отчета или обработки во внешний файл модуль менеджера будет потерян. Поэтому нужно учесть этот момент, доработать внешний отчет, например, добавив нужные процедуры в модуль объекта.
Альтернативный вариант – создать расширение, в котором реализовать новый отчет, модуль менеджера в таком случае будет доступен.
Читайте также: