Фиксируем колонку в отчете на СКД
Задача
. достаточно простая. Нужно создать отчет на СКД, который выводит остатки по номенклатуре в разрезе складов. Рассмотрим два варианта решения.
Первый будет осуществлен стандартными возможностями СКД без единой строчки кода. Второй вариант будет усложнен дополнительным условием при выводе отчета. Но обо всем по порядку.
Стандартные возможности
Система компоновки данных имеет стандартные возможности по фиксации колонок в отчете. Настройки фиксации как таковые отсутствуют, но мы можем влиять на нее через изменение структуры отчета. Например, если нам нужно в отчете, скриншот которого представлен выше, сделать фиксацию для колонки «Номенклатура», то достаточно настроить структуру вывода следующим образом:
Тогда при формировании отчета мы получим необходимый результат. Фиксация будет происходить для всех полей, которые находятся в разделе «Строки».
Таким образом, без единой строчки кода, используя только стандартные возможности СКД, мы решили задачу с фиксацией колонки в отчете. Но что, если нам нужно зафиксировать не только первую колонку «Номенклатура», но и первую колонку склада (в нашем случае это «Главный склад»). Стандартные возможности СКД тут не помогут, пойдем другим путем.
Другой путь
Используя отчет из предыдущей части статьи зафиксируем первую колонку «Склад» в выводимом табличном документе. Для этого программно сформируем отчет в обработке «ПриКомпоновкеРезультата» модуля объекта отчета. Листинг этой процедуры-обработчика представлен на следующем листинге:
Чтобы провести фиксацию первой колонки выводимого склада, выполним вывод отчета в табличный документа. Затем установим фиксацию в табличном документе слева в значение 3 (3 ячейки).
Почему фиксация имеет значение именно 3? Обратимся к следующему скриншоту:
И так, задача решена. Конечно, не универсальным образом, но пример изначально планировался простым.
На изображении показано количество ячеек от левого края, для которых нужно включить фиксацию.
В результате формирования отчета мы увидим следующий результат:
Заключение
В предыдущих статьях мы не раз изменяли табличный документ после работы процессора вывода компоновки данных. Этот пример еще раз показывает, что, работая с программным формированием отчета на СКД, мы можем создать отчет практически любой сложности, с любым внешним видом.
Базовый принцип программирования управляемой формы в 1С
Цель статьи – показать применение шаблонов Remote Facade и Data Transfer Object к структуризации кода, управляемой формы в среде 1С 8.2.
Введение
Начнем с небольшого описания понятия «управляемая форма» и связанных концепций платформы 1С. Знатоки платформы могут пропустить этот раздел.
Все дальнейшие рассуждения будут о правой части иллюстрации, о том, как структурировать код модуля и какие принципы позволят реализовать эффективное клиент-серверное взаимодействие.
Обозначим проблему
Прошло уже несколько лет как новая версия платформы 1С активно используется и выпущено множество решений (конфигураций) как фирмой 1С, так и ее многочисленными партнерами.
Сложилось ли за это время у разработчиков единое понимание принципов клиент-серверного взаимодействия при создании форм, и изменился ли подход к реализации программных модулей в новых архитектурных реалиях?
Рассмотрим структуру кода (модуль формы) в нескольких формах одной типовой конфигурации и попробуем найти закономерности.
Под структурой будем понимать секции кода (чаще всего это блоки комментариев) выделенные разработчиком для группировки методов и директивы компиляции этих методов.
Пример 1:
Зачем нужна структура кода?
Почему существующий стандарт разработки от фирмы 1С не помогает?
Шаблоны проектирования или мудрость поколений
Примеры шаблонов в платформе 1С
Прикладной программный интерфейс доступный разработчику при разработке управляемой формы, содержит много примеров данных принципов.
Например метод ОткрытьФорму(), типичный «огрубленный» интерфейс.
Сравните с принятым в v8.1 стилем.
Структурируем код
Заметки из Зазеркалья
Реализовано в версии 8.3.7.1759.
Чтобы было понятно, о чём идёт речь в этой статье, необходимо сделать небольшое пояснение.
Особенностью управляемых форм является то, что разработчик не формирует внешний вид формы непосредственно. Разработчик только создаёт описание формы с помощью некоторых логических правил. Исходя из этих правил, платформа самостоятельно генерирует визуальное представление формы. Причём это визуальное представление зависит от размеров окна, в котором отображается форма. Одна и та же форма, показанная в узком окне или в окне, раскрытом на весь экран, будет иметь разное визуальное представление.
Так вот, та часть платформы, которая формирует визуальное представление формы, называется механизмом размещения элементов в форме.
Почему понадобился новый механизм?
Во-первых, прежний механизм, к сожалению, имел недостатки. Наиболее значительный из них заключался в том, что многие изменения свойств элементов формы, выполняемые на клиенте, требовали обязательного обращения к серверу. А любое обращение к серверу ведёт к замедлению работы.
Во-вторых, мы оценивали опыт использования управляемых форм и обнаружили ряд критичных потребностей, которые необходимо было реализовать.
И, в-третьих, мы хотели заложить в новый механизм возможности будущего развития.
Основные изменения
Схематично представить работу прежнего механизма можно следующим образом:
Разработчик в конфигураторе создаёт дерево элементов формы и задаёт свойства элементов. В тот момент, когда прикладное решение должно показать форму пользователю, происходит следующее. Сначала на сервере платформа создаёт описание визуальной формы. Потом это описание передаётся на клиента. А на клиенте визуализатор формирует то изображение, которое увидит пользователь.
Основное действие, которое выполнялось на сервере при создании описания визуальной формы, это расчет длин строк. Имеются в виду всевозможные заголовки, надписи и так далее. Зная длины строк можно уже просчитать расположение элементов в форме.
Так как эта операция выполнялась на сервере, присутствовали два негативных момента. Во-первых, для расчёта использовались не те шрифты, которые будут использованы на клиенте, а те, которые установлены на сервере. А они могут отличаться, особенно если речь идёт о разных платформах (Windows, Linux). Или даже нужные шрифты могут быть совсем не установлены на сервере. Во-вторых, для расчёта длин использовался тот «движок» растеризации шрифтов, который есть на сервере. А он может работать не совсем так, как механизм рендеринга текстовых строк, существующий на клиенте в интернет-браузере, например. В результате могли появляться формы либо с «обрезанными» текстами, либо, наоборот, с чересчур широкими надписями.
Другая проблема заключалась в том, что отсутствовала какая-либо адаптация к размеру окна, в котором форма будет показана у клиента. Фактически на сервере описание формы создавалось исходя из минимально возможного размера окна, и дальнейший успех её отображения зависел уже от того, насколько хорошо она «умеет» растягиваться.
В новом механизме генерацию описания визуальной формы, которая раньше целиком выполнялась на сервере, мы разделили на две части, серверную и клиентскую:
Серверная часть стала существенно меньше. В ней не выполняется никаких расчётов. На сервере создаётся только «заготовка» описания, которая не содержит точных длин текстовых полей, и в ней не разрешены элементы адаптивности. На сервере обрабатывается видимость элементов, но только та, которая определяется функциональными опциями, и та, которая установлена пользователем. Но тут и нельзя иначе, потому что сами функциональные опции доступны только на сервере. А интерактивное изменение настроек пользователем в любом случае приведёт к серверному вызову.
В результате получается некий «полуфабрикат» визуального представления формы, который передаётся на клиента.
На клиенте производится необходимая доработка описания визуальной формы. Рассчитываются длины строк, рассчитываются элементы адаптивности, связанные с размерами клиентского дисплея, и отрабатывается видимость. После этого, как и раньше, начинает работать визуализатор, который и создаёт окончательную форму, которую видит клиент.
Благодаря тому, что расчёт длин строк производится на клиенте, удалось избавиться от ненужных и неаккуратных «щелей» между элементами. А отработка видимости на клиенте без обращения к серверу позволила ускорить работу форм. Потому что включение/выключение видимости элементов формы это одна из наиболее частых операций.
Некоторые новые возможности
Элементы адаптивного интерфейса
Новый механизм размещения элементов в форме не только улучшает те возможности, которые имелись ранее, но и добавляет новые возможности. Например, он адаптирует внешний вид формы к размерам клиентского дисплея. Для этого используются несколько путей.
Во-первых, выполняется автоматический перенос строк с подстройкой высоты заголовков и декораций. Как это работает, можно посмотреть на рисунке:
Если в форме есть длинные строки, которые можно разбить на отдельные слова, то такие строки переносятся, если в этом есть необходимость. Соответственно высота формы увеличивается, потому что нижняя её часть «отъезжает» вниз. В результате форма будет выглядеть нормально даже на узких экранах. Более того, этот механизм работает динамически, а значит, вы можете сжимать форму в реальном режиме времени, и вместе с этим будут переноситься длинные строки.
Автоматический перенос работает для заголовков элементов, заголовков групп, текстовых декораций и текста в кнопках, имеющих вид Гиперссылка.
Третий элемент адаптивности, это автоматическое определение количества колонок у переключателя или тумблера. Раньше, если не было специальных указаний, количество колонок устанавливалось максимальным, и он выводился в одну строку. Теперь, в той же ситуации, анализируется ширина формы, и устанавливается такое количество колонок, при котором переключатель/тумблер будет выглядеть на экране хорошо.
Горизонтальное и вертикальное выравнивание
Раньше такая возможность отсутствовала, и для реализации нестандартного выравнивания приходилось выдумывать разные «хитрости». Теперь форме и группе можно указать, каким образом должны выравниваться её элементы по вертикали и по горизонтали. Например, на рисунке ниже, группа кнопок показывает три возможных варианта выравнивания: Лево, Центр и Право:
На этом рисунке кнопки размещены в обычной группе, которая растягивается по горизонтали. Расположение кнопок внутри группы управляется свойством группы ГоризонтальноеПоложениеПодчиненных.
Управление внешним выравниванием
Например, у вас есть форма, в которой расположены поле Подразделение, группы Адрес и Телефон. Прежний механизм выравнивал поля этих групп так, как показано на левом рисунке. Поля в форме выравнивались между собой, и поля в каждой группе выравнивались между собой.
Теперь у вас есть возможность устанавливать группам сквозное выравнивание, в результате чего, например, все поля формы будут выровнены одинаково. Этот вариант показан на правом рисунке.
Более того, вы можете управлять сквозным выравниванием для каждой группы отдельно. Поэтому можете, например, отключить сквозное выравнивание для группы Телефон, и тогда форма будет выглядеть так, как показано на правом рисунке.
Выравнивание элементов и заголовков
Ограничение максимальной ширины элементов
Раньше, если вы указывали элементу, что он должен растягиваться, то элемент растягивался до тех пор, пока это возможно. Например, на весь экран. Для одних элементов это было хорошо (например, поле HTML), а для других элементов это могло быть и не очень хорошо. Например, для числовых полей. Потому что числовые данные, или кнопки, управляющие полем, оказывались где-то далеко справа.
Теперь у элементов появились булевы свойства, с помощью которых можно установить режим автоматического растягивания по ширине или высоте. В этом режиме платформа самостоятельно определяет, до каких границ можно растягивать поле. Если автоматический режим отключить, тогда платформа будет вести себя так же, как и раньше. Если вы указываете конкретную ширину/высоту поля, будет использоваться она. А если вы указываете значение 0, то элемент будет растягиваться до тех пор, пока это возможно.
Управление расстоянием между элементами
Отключение растягивания формы
Мы реализовали ещё один, новый режим работы формы, который отключает растягивание её элементов по вертикали. Этот режим будет полезен для форм, содержащих небольшое количество элементов.
Отключение прокрутки у страниц
Для форм, содержащих большое количество элементов, мы тоже несколько изменили поведение. Теперь вертикальная прокрутка у страниц не появляется. Вертикальная прокрутка теперь может быть у самой формы или внутри элементов формы, таких, как таблица, табличный документ и так далее. А страница формы всегда будет иметь полную высоту. Это должно облегчить работу пользователей, потому что большое количество скроллеров в форме часто смущает и сбивает с толку.
Резюме
В этой обзорной статье мы перечислили лишь основные возможности, которые даёт новый механизм размещения элементов в форме. Но не менее важно на наш взгляд и то, что в этом механизме заложен существенный запас для будущего развития.
Новое в управляемых формах в «1С:Предприятие 8.3»
(бесплатная статья по Программированию в 1С)
из цикла статей «Первые шаги в разработке на 1С»
О чем эта статья
Эта статья продолжает цикл статей «Первые шаги в разработке на 1С». Материал предполагает, что вы уже ознакомились с предыдущими нашими статьями, посвященными интерфейсу. В это же статье мы продолжим знакомство с новыми возможностями интерфейса «Такси» и рассмотрим, какие интересные новшества получили управляемые формы в этом интерфейсе.
Применимость
В статье рассматривается интерфейс «Такси» конфигурации, разработанной на платформе 1C 8.3.5.1098. Дополнения к текущим релизам платформы (8.3.11) приведены в заключении. Поэтому вся представленная информация актуальна.
Новое в управляемых формах в «1С:Предприятие 8.3»
Разработчики платформы «1С:Предприятие 8.3» в очередной раз основательно поработали над удобством работы пользователей с управляемыми формами.
Ввод по строке
Ранее, в полях ввода, при вводе с клавиатуры начальных символов, система искала подходящие элементы.
Однако зачастую пользователям необходимо осуществлять поиск не только по первым символам наименования, но и в произвольном месте названия.
В конфигураторе у ссылочных объектов метаданных для настройки ввода по строке, была создана отдельная закладка “Поле ввода”:
На ней представлены следующие возможности для формирования списка выбора при вводе по строке:
В свойстве “Способ поиска строки при вводе по подстроке” можно выбрать – следует ли искать только по первым символам строки или в любой ее части.
В пользовательском режиме поиск по любой части строки выглядит следующим образом: пользователь последовательно вводит с клавиатуры символы, а система осуществляет поиск.
Причем не только с первых букв названия, но и по вхождению набранной строки:
Естественно, использование поиска по любой части строки может привести к ухудшению производительности системы, особенно при большом объеме данных.
В файловом режиме пока пользователь набирает строку, поиск производится в фоне только в том случае, если в этот момент не выполняется другое фоновое или регламентное задание.
Если установлена соответствующая настройка, то при вводе данных в поле ввода может быть использован полнотекстовый поиск.
Во время полнотекстового поиска будут найдены как целые слова, так и строки, в которых набранные символы являются частью целых слов (используется оператор * полнотекстового поиска).
Например, пользователь вводит следующие части слов в поле ввода, система во всплывающем окне отображает найденные при помощи механизма полнотекстового поиска варианты:
Результаты полнотекстового поиска, соответствующего введенной поисковой строке, приведены на рисунке:
Напомним, что в платформе 8.3 появилась возможность переопределить представление ссылочного типа данных при помощи процедур ОбработкаПолученияПредставления и ОбработкаПолученияПолейПредставления в модуле менеджера объекта.
Для увеличения нажмите на изображение.
При совместном использовании этого функционала и ввода по строке существует следующая особенность.
Указанные выше обработчики не влияют на представление значений в списке выбора – в списке отражается основное представление объекта.
Однако после выбора в поле отображается ожидаемое переопределенное представление объекта.
Для увеличения нажмите на изображение.
Разработчики считают, что ошибок в таком поведении платформы нет, и что более ценно показать, почему конкретный результат найден (выделить, например, подстроку, по которой объект был найден), чем отобразить оторванное от результата поиска представление соответствующего значения.
Рассмотренные выше свойства ввода по строке задавались на уровне всего объекта метаданных.
В конкретном месте конфигурации разработчик может переопределить эти свойства.
Например, при помощи обработчиков событий АвтоПодбор и ОкончаниеВводаТекста конкретного поля ввода или при помощи обработчика события ОбработкаПолученияДанныхВыбора в модуле менеджера объекта.
Для этого в этих процедурах предназначен параметр с именем Параметры типа Структура, в свойствах которой содержатся способ поиска строки, режим получения данных выбора, настройка использования данных выбора.
Для увеличения нажмите на изображение.
Выпадающий список для поля ввода
В платформе 8.3 выпадающий список для поля ввода получил дополнительную функциональность для повышения удобства работы с системой.
Теперь этот список может отображать историю выбранных ранее значений. Список с историей показывается на экране при установке курсора в поле, при нажатии кнопки Выбрать из списка, или кнопки на клавиатуре со Стрелкой вниз.
Включить отображение истории можно у полей ввода, связанных с данными типа справочник, документ, бизнес-процесс, задача, план видов характеристик, план видов расчета, план счетов и план обмена. В конфигураторе для этого предусмотрено свойство, расположенное на закладке “Поле ввода”:
Для увеличения нажмите на изображение.
Использование истории можно переопределить для конкретного реквизита объекта или элемента формы.
Кроме этого, если в списке поля ввода пользователь не нашел интересующего элемента, он может нажать кнопку “Показать все” для открытия формы списка, чтобы выбрать элемент из всего справочника.
Также в списке поля ввода есть команда “Создать новый объект”. При этом будет открыта форма нового элемента.
В этой форме пользователь заполняет необходимые поля. После записи и закрытия формы ссылка на только что созданный элемент будет подставлена в поле ввода.
Типовой шаблон использования команды “Создать новый элемент” выглядит следующим образом. Пользователь вводит название нужного элемента в поле ввода.
Если такого элемента в базе данных система не обнаружит – будет выведено сообщение об этом. После нажатия кнопки в списке, на экране откроется форма нового элемента с заполненным наименованием.
Рассмотренные новшества позволяют увеличить скорость ввода информации в систему.
Сохранение настроек динамических списков
В платформе 8.3 настройки динамического списка можно сохранять автоматически. Для этого в конфигураторе, для нужного реквизита формы, необходимо установить свойство “Автоматическое сохранение пользовательских настроек”. По умолчанию, при создании списка эта настройка включена.
У корневого элемента конфигурации появилось новое свойство – Хранилище пользовательских настроек динамических списков.
Это свойство выбирается из списка хранилищ настроек, определенных в конфигурации.
Для увеличения нажмите на изображение.
Настройка списков в пользовательском режиме вызывается при помощи соответствующего пункта меню:
Внешний вид формы похож на настройку отчетов.
Для увеличения нажмите на изображение.
Условия, по которым выполнен отбор списка, автоматически отображаются в нижней части настроек. Эти настройки будут включены в форму списка.
В режиме конфигуратора для этого необходимо заполнить свойство таблицы формы Группа пользовательских настроек.
В нем нужно указать отдельную группу формы, внутрь которой и будут добавляться элементы для отображения отбора.
При такой настройке форма будет иметь поля в виде “быстрых отборов”.
Для увеличения нажмите на изображение.
Если пользователь настроил список под себя, то настройки автоматически сохранятся и при повторном открытии список будет иметь тот же самый вид.
Режим просмотра динамического списка (список, дерево, иерархический список) сохраняется вместе с настройками элементов формы.
Для одного списка у пользователя может быть сохранено несколько различных вариантов настроек.
Журнал документов
Если режим совместимости конфигурации установлен в значение “Не использовать”, то для динамического списка, у которого в качестве основной таблицы указана таблица журнала документов, кнопка “Создать” автоматически формируется в виде подменю со списком документов, входящих в журнал.
Для увеличения нажмите на изображение.
Этим упростилось создание новых документов пользователем из формы журнала. Также стало возможным быстро создавать на командной панели формы отдельные кнопки для создания нового документа определенного вида.
Для этого была создана стандартная команда СоздатьПоПараметру. Если эта команда назначена кнопке на форме, то становится доступным свойство Параметр, в котором можно выбрать тип создаваемого документа при нажатии на эту кнопку.
Для увеличения нажмите на изображение.
В пользовательском режиме эта кнопка будет выглядеть следующим образом:
Для увеличения нажмите на изображение.
Т.к. материал в статье описан для платформы 8.3.5, то актуализируем его.
На этом знакомство с управляемыми формами в интерфейсе «Такси» мы завершим, но в следующей статье познакомимся с новыми возможностями, которые представила платформа «1С:Предприятие» редакции 8.3.
PDF-версия статьи для участников группы ВКонтакте
Если Вы еще не вступили в группу – сделайте это сейчас и в блоке ниже (на этой странице) появятся ссылка на скачивание материалов.
Статья в PDF-формате
Вы можете скачать эту статью в формате PDF по следующей ссылке: Ссылка доступна для зарегистрированных пользователей)
Ссылка доступна для зарегистрированных пользователей)
Ссылка доступна для зарегистрированных пользователей)
Ссылка доступна для зарегистрированных пользователей)