Как частное мнение, насколько это в целом удобно? Я с НПД что-то подумываю перейти. Понятно что 8 больше чем 6, но возня с документами поднадоела. Все боятся, чтобы налоговая отношения трудовыми не признала, задания на работу, критерии выполнения работ, чеки им пришли, статус самозанятого подтверди и т.д. и т.п.
Код-то рабочий, но так и микроскопом гвоздь тоже можно забить. Ваши "советы" не помогут, а только запутают.
Вы хронически путаете элементы формы и реквизиты. У вас типизированные реквизиты, но вы вечно тянетесь к элементам, что приводит к появлению монструозных выражений "СокрЛП(ДатаВыпуска) = ". ."". ТекстРедактирования для решения вашей задачи ни разу вообще не нужен. ОбработкаВыбора - тоже. Определитесь, с чем вы работаете, с данными или их отображением, и вы поймете, что Обновить() и ОбновитьОтображениеДанных() вам также не нужны. Реально, откройте для себя уже обработчик ПриИзменении.
Попробуйте разобраться, что такое динамический список и как он работает. Сейчас - вы не понимаете. Любой пользователь, который будет достаточно любопытен, чтобы нажать "Еще - Настроить список..." запросто сломает вам всю логику, начиная от обращения к параметрам по индексу, и заканчивая обращением к полю Подразделение, которого может и не быть. Скажите честно, вы же не поставили флаг "Использовать всегда" у подразделения в настройках списка?
Динамический список - не более чем визуализация в коллекцию формы результата исполнения некоего запроса, выстроенного СКД по некоторым параметрам. Строки списка отдельно не существуют, именно поэтому различается поведение при перетаскивании. Строка таблицы/дерева значений существует независимо от того, видно ее на форме или нет, строка списка нет. И это не "секрет динамического списка". Собственно, зачем пихать таблицу материалов в динамический список, чтобы потом героически превозмогать перетаскивание, при этом не используя ни единой возможности списка, вообще непонятно. Результат запроса загрузить в таблицу значений - не?
Ну и по мелочи, добавить новый справочник, чтобы в его единственном элементе хранить порядковые номера корректировок, серьезно?
Регистр на шесть измерений? Документ/Номер корректировки/Идентификатор строки?
Вы же в курсе, что в зависимости от установки параметров в данном случае фактически будут исполняться разные запросы?
Конструкция, которую вы называете тихими параметрами, нужна для построения пользовательского отбора. А пользовательский отбор будет работать и без этих телодвижений, т.к. в настройках списка включена опция "автозаполнение доступных полей". Более того, СКД сама еще и дочерние поля для использования в отборе подтянет.
Реквизит "ПодразделениеВыпуска" имеет ссылочный тип, какая обработка выбора, какой текст редактирования? Задача отфильтровать список по подразделению, равно как и сбросить отбор, в данном случае решается одним вызовом одной процедуры:
Так канонически вообще "ГДЕ Документ.Проведен". "Проведен" само по себе булево. И или проведен или пометка удаления, при нормальной работе. Свойства списка через БСП, а параметры зачем-то вручную. Как ниже сказали <и> вместо "Между". А фигурные скобки вообще инструкция для построителя. (А что это?) Почему обработка выбора, а не при изменении, к самой обработке выбора тоже есть вопросы. Почему ТекстЗапросаДокументы в контекстном вызове.
Как частное мнение, насколько это в целом удобно? Я с НПД что-то подумываю перейти. Понятно что 8 больше чем 6, но возня с документами поднадоела. Все боятся, чтобы налоговая отношения трудовыми не признала, задания на работу, критерии выполнения работ, чеки им пришли, статус самозанятого подтверди и т.д. и т.п.
Код-то рабочий, но так и микроскопом гвоздь тоже можно забить. Ваши "советы" не помогут, а только запутают.
Вы хронически путаете элементы формы и реквизиты. У вас типизированные реквизиты, но вы вечно тянетесь к элементам, что приводит к появлению монструозных выражений "
СокрЛП(ДатаВыпуска) = ". ."". ТекстРедактирования для решения вашей задачи ни разу вообще не нужен. ОбработкаВыбора - тоже. Определитесь, с чем вы работаете, с данными или их отображением, и вы поймете, что Обновить() и ОбновитьОтображениеДанных() вам также не нужны. Реально, откройте для себя уже обработчик ПриИзменении.Попробуйте разобраться, что такое динамический список и как он работает. Сейчас - вы не понимаете. Любой пользователь, который будет достаточно любопытен, чтобы нажать "Еще - Настроить список..." запросто сломает вам всю логику, начиная от обращения к параметрам по индексу, и заканчивая обращением к полю Подразделение, которого может и не быть. Скажите честно, вы же не поставили флаг "Использовать всегда" у подразделения в настройках списка?
Динамический список - не более чем визуализация в коллекцию формы результата исполнения некоего запроса, выстроенного СКД по некоторым параметрам. Строки списка отдельно не существуют, именно поэтому различается поведение при перетаскивании. Строка таблицы/дерева значений существует независимо от того, видно ее на форме или нет, строка списка нет. И это не "секрет динамического списка". Собственно, зачем пихать таблицу материалов в динамический список, чтобы потом героически превозмогать перетаскивание, при этом не используя ни единой возможности списка, вообще непонятно. Результат запроса загрузить в таблицу значений - не?
Ну и по мелочи, добавить новый справочник, чтобы в его единственном элементе хранить порядковые номера корректировок, серьезно?
Регистр на шесть измерений? Документ/Номер корректировки/Идентификатор строки?
Двойственное ощущение. С одной стороны, за рефакторинг подобного "кода" мне неплохо платят. С другой, даже за деньги неприятно в этом ковыряться.
Извините, но вы демонстрируете полное непонимание того, как это в принципе работает.
Какой, к черту, текст редактирования для ссылочного поля?
Оценочно выходит 1,68 МВ, т.к. стандартная величина пробоя при н.у. 3 кВ/мм. Это опечатка, или пропущены какие-то существенные уточнения?
Вы же в курсе, что в зависимости от установки параметров в данном случае фактически будут исполняться разные запросы?
Конструкция, которую вы называете тихими параметрами, нужна для построения пользовательского отбора. А пользовательский отбор будет работать и без этих телодвижений, т.к. в настройках списка включена опция "автозаполнение доступных полей". Более того, СКД сама еще и дочерние поля для использования в отборе подтянет.
Реквизит "ПодразделениеВыпуска" имеет ссылочный тип, какая обработка выбора, какой текст редактирования? Задача отфильтровать список по подразделению, равно как и сбросить отбор, в данном случае решается одним вызовом одной процедуры:
Так канонически вообще "ГДЕ Документ.Проведен". "Проведен" само по себе булево. И или проведен или пометка удаления, при нормальной работе. Свойства списка через БСП, а параметры зачем-то вручную. Как ниже сказали <и> вместо "Между". А фигурные скобки вообще инструкция для построителя. (А что это?) Почему обработка выбора, а не при изменении, к самой обработке выбора тоже есть вопросы. Почему ТекстЗапросаДокументы в контекстном вызове.
А почему у нас ERP тормозит...