1с проверитьвывод как работает

Обновлено: 22.01.2025

что-то вы вообще не так делеает. Прочиайие проПроверитьВывод, там и примеры есть.

Вы же два раза одно и то же кидаете на страницу

получается одну и ту же область два раза выводите.

Два раза ничего не выводится, вывод осуществляется 1 раз в строке
ТабДок.Вывести(Детали);
А далее область добавляется в массив
МассивВыводимыхОбластей.Добавить(Детали);

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

(3) Кто нибудь может подсказать, проблема все таже в типовой КА 1.1
при печати УПД первый лист режет по средине, получается шапка, заголовок таблицы и 2 строки таблицы, потом следующая с повторяющимся заголовком таблицы (норм)
В УчетНДС.ВывестиСчетФактуруВТабличныйДокумент()
Как раз построчно используется ПроверитьВывод() но толку мало, все уезжает, избился но не хочет по нормальному печатать и все тут.

Кусок кода внутри цикла ОбластьМакета вывод строки таблицы

(38) Помогло в моем сеансе удалить из хранилища настроек "ПАРАМЕТРЫ_ПЕЧАТИ_УниверсальныйПередаточныйДокумент", непонятно как они слетают и как часто придется мочить :)

Ну первое, что в голову приходит - это что у самого табличного документа сделаны настройки (колонтитулы там, или автомасштаб), а у массива областей - нет. Может быть есть смысл скопировать документ после настроек, использовать копию вместо массива и очищать как раз табличный документ.

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

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

С массивом на через каждую строчку не дробит, это как раз происходит без применения массива. А так массив очищается вполне корректно.

До меня тоже теперь наконец то дошло, спасибо YNik и spacecraft .
Так как это метод самого табличного документа, то мы при при проверке уже имеем данные самого табличного документа, к этому прибавляется то, что передали в качестве аргумента и таким образом проверяется следующее условие ТабличныйДокумент + МассивОбластей > Площадь листа и делается вывод поместится или нет.

Кстати код приведенный YNik , можно и нужно сократить, вообще исключив массив из употребления и передавать саму область для проверки и все будет прекрасно работать! Ура все получилось в лучшем виде :)

(10) ger_kar, сократить можно если вы проверку делаете одной строки.

А вот у меня такая штука не прокатила!

Проблема в том что у документа есть автомасштаб и что с ним делать? Выводит пол страницы пустой! (13) spacecraft, этот параметр я уже установил в начале при создании: (14) Xershi, тогда ой. Этот признак используется при печати. Вполне может не обрабатываться при проверке вывода. (15) spacecraft, так что выходит, мне нужно вручную написать алгоритм проверки количество умещаемых строк на странице?
Проблема в том что в одной строке может быть большой текст, как этот нюанс вычислять? В чем особенность проверки этого метода кто в курсе? Он что без автомасштаба проверку в "мТабДок" делает?

Новый формат строк улучшил ситуацию. Стало на странице чуть больше элементов. Похоже все дело в формате.

(17) Xershi, У меня вот так выполняется проверка. Все красиво работает.

Смысл в следующем:
Есть ТЗ. Есть подвал. Нельзя что бы подвал выводился сам на отдельной странице. Последнюю строку ТЗ добавляю в массив. Потом добавляю туда подвал. Если не выводится тогда добавляю разделитель и вывожу то что есть в массиве (последняя строка + подвал).

(17) Xershi, проверил у себя. АвтоМасштаб достаточно только в мТабДок.
А вот с МассивТаблицОбластей и правда не понятно зачем вообще его использовать?

(23) spacecraft, я его делал, для того чтобы исключить не попадание последней строки. Т.к. строка добавляется по кускам и вот 3 кусок строки может быть на 5 строк и по итогу не поместится на страницу.

Поэтому вот этот нюанс так думал обыграть.

Сейчас внимательно ваш код проверю.

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

(24) Xershi, не совсем понял. Есть "строка", которая может занимать несколько строк вывода? И что нужно? Совсем ее не выводить в текущей странице, если полностью не помещается? Или выводить частично, с переносом на другую страницу? (25) spacecraft, спасибо помогли понять, что там происходит. Убрал массив и переписал код, чтобы проверка шла в конце(когда строка полностью сформирована) со строкой дублером и тогда вся страница заполнилась полностью. Но я убрал оглавление для вывода чтобы проверить результат. Сейчас попробую с оглавлением вывод сделать. Если попрет, то вопрос решен. (18) 6есик, чтобы дублировать шапку на каждой странице. У меня табличный документ из 2 макетов для прайс-листа с оглавлением.

(19) Xershi, ну это я понимаю добавляете шапку на каждую новую страницу :

А зачем после этого ее добавлять в массив для проверки на вывод ? Ведь шапку вы уже вывели в табличный документ и проверка на вывод уже будет сопоставлять ваш массив и то свободное место в таб доке которое осталось после вывода шапки.

Понял в чем мои косяки и тогда проверка корректно все обработала!
Всем спс! (27) Xershi, я бы оптимизировал этот код. Как и в приведенном мной выше.
(28) spacecraft, это уже не критично я считаю. Кстати на практике такая оптимизация дает, хоть какой-то профит? (29) Xershi, как минимум избегает дублирование кода.
Честно говоря, просто бьет по глазам. Щас столкнулся с проблемой проверить вывод в ут 11.2 печатает тор12 с 1 номенклатурой в 2 листа
1 лист - путстая строка номенклатуры а на 2-м единственная номенклатура
дело должно быть в начтройках принтера по умолчанию но там вроде все нормально
что за чудеса непонятно (31) piffoff, я добавлял проверку на 1-ю строку, чтобы не выполнялся ПроверитьВывод:
Еще замечание в копилку. Сначала надо определить размер страницы, поля, автомасштаб и т.д. И уже после этого - проверять вывод. (33) Спасибо!! Пока не прописал вручную все (! слева/справа обязательно) поля - ПроверитьВывод() выполнялось некорректно

Добрый день. вывожу на печать доработанный табель.
На каждой странице должна быть шапочка ФИО, ТабНомер, Должность, Дни с 1 - 15, Итого15, 16 -Последний день, Итого за месяц. У сотрудника количество строк заранее не известно, т.к. зависит от КолВВ(количество видов времени, которые у него были за месяц. Каждый вид времени печатается на новой строке).

2 раза перенос на след. страницу делает и все. Больше разделитель не ставится.

Пока ВыборкаСотрудник.Следующий() Цикл

ОблСтрокаНомСтроки = Макет.ПолучитьОбласть("R" + СТРОКА(16 + КолСтрокВывели) + "C1:R" + СТРОКА(16 + КолВВ - 1 + КолСтрокВывели) + "C1");
МассивВыводимыхОбластей.Очистить();
МассивВыводимыхОбластей.Добавить(ОблСтрокаНомСтроки);

Если Не ПроверитьВыводТабличногоДокумента(ТабДок, МассивВыводимыхОбластей) Тогда

КолонтитулВсегда = Макет.ПолучитьОбласть("Колонтитул|КолонкиВсегда");
ТабДок.Вывести(КолонтитулВсегда);

Колонтитул29 = Макет.ПолучитьОбласть("Колонтитул|Колонка29");
Колонтитул30 = Макет.ПолучитьОбласть("Колонтитул|Колонка30");
Колонтитул31 = Макет.ПолучитьОбласть("Колонтитул|Колонка31");
КолонтитулВсегоОтработаноЗаМесяц = Макет.ПолучитьОбласть("Колонтитул|ВсегоОтработаноЗаМесяц");

Если ПоследнийДень > 28 Тогда
ТабДок.Присоединить(Колонтитул29);
КонецЕсли;
Если ПоследнийДень > 29 Тогда
ТабДок.Присоединить(Колонтитул30);
КонецЕсли;
Если ПоследнийДень > 30 Тогда
ТабДок.Присоединить(Колонтитул31);
КонецЕсли;
ТабДок.Присоединить(КолонтитулВсегоОтработаноЗаМесяц);
КолСтрокВывели = КолСтрокВывели + 3;

КонецЕсли;
ТабДок.Вывести(ОблСтрокаНомСтроки);
КонецЦикла

Подскажите, пожалуйста, где искать ошибку?

(34) Только что с похожей проблемой столкнулся, выводились несколько разделителей в Т-13, и все, пол отчета без них.
Дело оказалось в ширине колонок 5,6,7 и 20, они в стандартном почему то уже остальных, остальные по 3, а эти 2.63-2.88, и вот кто-то с коллег видно расширил, но не у всей колонки, а у диапазона, шапка осталась уже с подвалом.
Уменьшил ширину колонки с табельным на 1.1, пунктир справа выровнялся, и ПроверитьВывод заработал как задумывалось.

Добавлю в копилку свои 5 копеек.
Была задача выводить на каждом листе внизу логотип организации (печать договоров и приложений к ним).
Естественно пользовался методом ПроверитьВывод(), для того чтобы определять помещается ли выводимая область на лист вместе в логотипом, и если нет, то вывожу пустые строки пока есть место, потом логотип и горизонтальный разделитель страниц. Пустые строки не очень большой размера, чтобы логотип практически на одном и том же месте был.

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

Решение нашлось очень странное: если метод говорит, что не умещается, то получаем количество страниц Табличного документа, а потом снова проверяем, помещается или нет. И вот тут происходит чудо)), 1С вдруг неожиданно начинает считать, что теперь помещается и продолжает выводить до самого низа (а раньше было заметно, что несколько строк еще может поместиться в конце). Код ниже.

Если НЕ ТабДокумент.ПроверитьВывод(МассивОбластейВывода) Тогда
//вот тут уже выводится и пустые строки, и логотип, и разделитель и др. нужные области шапки нового документа
КонецЕсли;

Методика расследования причин медленной работы операции на примере открытия управляемой формы

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

Сбор и анализ стандартных данных

Разберем пример для операции открытия формы документа "Табель учёта рабочего времени".

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

Настройка технологического журнала на клиенте может быть такой:

Фильтр по имени процесса для нашей задачи избыточен и нужен для того, чтобы в случае ошибочной настройки такого лога на сервере не получить сбор всех событий для серверных процессов, что может занять значительный объем. С другой стороны, при осознанном включении такой настройки на сервере (если клиентские приложения запускаются там же, где может быть развернут и сервер приложений 1С:Предприятие) мы в отдельном каталоге Client_Full увидим данные только клиентских приложений (хотя при этом подкаталоги других процессов тоже будут созданы, но они буду пустыми). Свойство Interface не собираем, так как оно дублируется более "человек читаемым" свойством IName (хотя даже последнее нам в данном примере не обязательно нужно).

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

Замеры времени средствами БСП будут выглядеть следующим образом:

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

Замер отладчиком конфигуратора изображен на следующем рисунке:

Как видно, сумма длительности всех строк, связанных с открытием формы составила всего 1,523 секунды.

'00010101' + ТекущаяУниверсальнаяДатаВМиллисекундах() / 1000

а для миллисекунд взять остаток от деления на 1000 (то есть просто последние три цифры, обратите внимание на "779" на следующей картинке).

Точное время начала замера (минут:секунд.миллисекунд): 25:10.779

Точное время окончания замера (минут:секунд.миллисекунд): 25:23.801

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

Здесь видно, что соответствующий нашему замеру серверный вызов SCALL завершился примерно за 10,1 секунды, это соответствует интервалу между запросом VRSREQUEST и ответом VRSRESPONSE.
Причем время начала замера почти совпадает с началом вызова, то есть событием VRSREQUEST, что собственно ожидаемо, так как замер БСП начинается на клиенте и должен быть непосредственно перед командой открытия формы. А вот окончание вызова сервера случилось раньше, чем окончание замера, что значит, что эта разница во времени пришлась на часть работы клиентского приложения.

Итак, промежуточный итог по длительностям замеров разными способами показывает соответствие нашей ситуации ограничениям и выполнение неравенства: 1,5 < 10,1 < 13.

Стандартными инструментами не удается увидеть причину проблем низкой производительности работы (открытия) управляемой формы, поэтому воспользуемся следующими помощниками:

Отладчик операционной системы: Windows Performance Recorder для сбора метрик и Windows Performance Analyzer для их визуализации и анализа;
Анализатор сетевых протоколов Wireshark или прокси-сервер Fiddler Web Debugger.

Установим и запустим Windows Performance Recorder ("C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\WPRUI.exe"), укажем настройки:

После того, как их подготовили, перейдем в тонкий клиент 1С, откроем форму списка документов и непосредственно перед воспроизведением проблемной операции запустим сбор данных WPR (кнопка Start).

После открытия формы в тонком клиенте запись можно остановить и открыть ее для анализа. В открывшемся окне найдем по PID 5508 (его можно определить в диспетчере задач ОС или по логам ТЖ) наш тонкий клиент 1С и должны получить примерно следующую картинку:

По данным Windows Performance Analyzer видим, что у нас нет серьезной нагрузки по дискам, а поток тонкого клиента потребляет 100% ЦП на протяжении длительного времени вплоть до завершения замера.

Запомним этот результат и проанализируем траффик.

Запустим Wireshark и повторим проблемную операцию в тонком клиенте 1С:Предприятие с прямым подключением к серверу приложений 1С.

При сборе данных с помощью Wireshark (и отбору по пакетам с сервером-источником равным серверу приложений 1С:Предприятие) запуск открытия формы документа будет выглядеть примерно так:

Здесь каждая такая строка – это пакет (или если точнее, то "кадр", frame), который в свою очередь является частью общего большого пакета поверх протокола TCP (PDU – Protocol Data Unit). Если их сложить, получим пакет около 70 Кб. Стоит обратить внимание, что это будет размер с учётом сжатия, а если без него – то должны получить что-то около 2500 – 3500 Кб данных.

Устанавливаем и запускаем Fiddler, на панели инструментов ищем "Browse", выбираем любимый браузер и запускаем в нем необходимое нам приложение (информационную базу 1С:Предприятие). После запуска переходим в форму списка документов (готовимся воспроизвести сценарий), возвращаемся в Fiddler и включаем сбор траффика (кнопка F12), переходим в браузер и открываем форму документа. После её открытия сбор траффика можно отключить и заняться его анализом. Мы должны получить примерно следующее:

В данном дампе достаточно быстро находится относительно большой пакет искомого размера, выбираем его в списке слева, а в правой части окна переключаемся на страницу Inspectors, выбираем там просмотр заголовков (Headers), и так как у нас пакет является сериализованным json (Content-Type: application/json), то попросим Fiddler десериализовать его для нас.

После этого в окне предпросмотра отобразится древовидная структура ответа (response), которая передается с сервера на клиент и содержит так много данных. Далее нам необходимо проанализировать её и найти наиболее проблемные места. Может помочь кнопка Expand All, которая развернёт все элементы дерева, но это может занять некоторое время. Чтобы его сократить, сначала поймем, что именно нужно искать.

Подведем промежуточный итог:

Проблем с медленной работой прикладного кода 1С или запросов нет.
Большая часть времени открытия формы состоит из сетевого взаимодействия.
Размер пакета с формой подозрительно велик.
После получения пакетов имеем высокую утилизацию ЦП тонким клиентом 1С (или веб-клиентом).
Потерянное время находится где-то между окончанием/началом работы прикладного кода 1С и сетевой передачей.

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

Сама по себе большая и сложная форма с большим количеством экранных элементов и реквизитов. Наверное, редкий и точно не очень правильный случай, лучше такого избегать на этапе проектирования систем.
Простая форма, но много данных в реквизитах формы (включая данные объекта), в особенности:
- Хранилище значения, Строка(0);
- Большие коллекции (Таблица, Дерево, Список);
- Произвольный тип (концентрация проблем).
Так как наша проблема (у вас может быть по-другому) воспроизводится даже при очень небольшом количестве данных в ТЧ, и реквизитов у документа (т.е. объекта формы) совсем не много, то их мы не рассматриваем. Остаются реквизиты формы, не равные основному реквизиту "Объект".

Среди них находится несколько реквизитов, имеющих произвольный тип. Могут выглядеть так:

Сопоставляем эти данные с уже собранным ранее замером с помощью конфигуратора, и видим заполнение этих структур достаточно большим количеством элементов (например, можно 5059 в реквизите "СвойстваИзмерений").
Снова вернемся к дампу траффика в Fiddler и найдем там элемент, отвечающий за параметры формы (response/props). Увидим там примерно следующее:

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

Найдем прикладной код, заполняющий эти параметры, и убедимся, что данных там действительно достаточно много (2-3 Мб), и они представляют собой большое количество сложных вложенных структур.

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

Выводы и рекомендации

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

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

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

Принимая во внимание полученные таким образом данные, можно предложить следующие возможные пути решения:

Если не выводить пустую строку вообще, то как будет выглядеть весь документ?
(13) Чтобы строка заголовок (та в которой отображена нумерация столбцов) была всегда сверху очередной страницы. (15)Так если выводимая строка уже не проходит проверку на вывод, для чего выводить пустую строку вообще? Следующая строка(не пустая) и так должна быть сверху очередной страницы, т.к. там остаются колонтитулы верхний/нижний, которые у вас никак не заполняются.
Или я чего-то не понимаю?
(16)Выводимая строка по высоте больше одной строки. И если внимательно посмотреть код, пустая строка перед выводом тоже проверяется.

Это рабочее решение, если хочется отказаться от разрывов страниц.
Проблема в том, что это решение будет работать только в узком коридоре "правильных" настроек печати. Даже выгрузка в ворд уже похерит все форматирование.
(17) если решение ОЧЕНЬ сильно зависит от настроек печати, то это вообще не решение, ИМХО.
При сохранении в *.PDF такая же фигня, как и с *.DOC(X)?
(17) А можно поподробнее про правильные настройки печати? В описании ПроверитьВывод нигде об этом не говорится. Да, есть указание,что если у принтера минимальная ширина больше заданной, то метод будет фактически возвращать неправильное значение. Но это не мой случай. Поля я вообще оставил по умолчанию. Они по идее должны браться из настроек печати? Тогда никакого расхождения быть не должно. Логика этого метода ведь должна быть универсальна. Метод опирается на стройки печати на конкретной машине. И вне зависимости от машины должен возвращать верное значение именно для этой машины. То есть если принтер сможет распечатать макет в который всунут проверяемую область, тогда получим истину, в противном ложь. На разных машинах с разными настройками результат печати, я понимаю, может быть разный, но "разъезжания" такого быть не должно. Не пойму почему оно происходит.
Даже выгрузка в ворд уже похерит все форматирование. На самом деле у меня и с разрывом страницы при сохранении в ворд получается лажа. Остается куча места снизу. (16) Выводимая строка может быть, и как правило, высотой в несколько строк за счет установленного свойства переноса текста. Если она не влезает, то внизу может остаться место еще на пару строк. Их я и заполняю пустыми строками.
Следующая строка(не пустая) и так должна быть сверху очередной страницы Нет. Сначала должна быть строка заголовка с отображающей нумерацию столбцов (в макете отмечена как заголовок)
(20) предполагаю, у вас получается случай, когда на первую страницу не выводится строка высотой в 2 единицы, на вторую страницу - в 3 единицы -отсюда и лишние строки в начале страниц.

Такое решение, как уже было сказано выше, ОЧЕНЬ сильно зависит от настроек печати.
Ну и формирование ТабДок на сервере, вообще не понятно каким образом корреллирует с настройками печати клиента, тут я чую, вообще могут быть чудеса.

вот цитата из С-П:

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

Так понимаю - ваш случай.
предполагаю, у вас получается случай, когда на первую страницу не выводится строка высотой в 2 единицы, на вторую страницу - в 3 единицы -отсюда и лишние строки в начале страниц. Не пойму логики. Ну не выводится на данном листе строка в n-строк. Но я же и не вывожу её. Я вывожу один или несколько раз однострочную область. Как только перестает выводится "однострочная" строка, я вывожу другую однострочную (и она по идее долна идти с начала следующей страницы) и потом строку со слушателем.
Ну и формирование ТабДок на сервере, вообще не понятно каким образом корреллирует с настройками печати клиента, тут я чую, вообще могут быть чудеса. Тут, как мне кажется берутся все же настройки клиента, иначе этот метод теряет весь практический смысл.
Цитату из СП уже раз 20 перечитал ища в ней скрытый смысл. Но, как уже писал выше, из настроек печати у меня только автомасштаб стоит и ориентация страницы. Поля я не меняю в коде. Поля должны взяться из настроек принтера. И тогда метод должен возвращать правильные значения Не пойму логики. Ну не выводится на данном листе строка в n-строк. Но я же и не вывожу её. Я вывожу один или несколько раз однострочную область.
Предполагаю, что высота n-строчной строки <> сумме высот однострочных строк. Как такое может быть - запросто, учитывая, что единицы измерения высоты строки и ширины колонки очень специфические.

В 1С существует замечательный метод ПроверитьВывод, о котором, к сожалению, знают далеко не все разработчики.

В самой справке (в синтаксис-помощнике) об этом методе сказано следующее: «Проверяет, умещаются ли переданные табличные документы на страницу при печати».

А теперь поподробнее о том, что это за метод и для чего он существует…

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

Как это делается.

Метод табличного документа ПроверитьВывод(МассивТаблиц) имеет один параметр МассивТаблиц - массив из таблиц или табличный документ. Метод проверяет, если к существующему табличному документу (такому, какой он есть сейчас) добавить еще строки – МассивТаблиц – будет ли произведен переход на следующую, новую страницу. Если говорить проще, «влезет» МассивТаблиц на текущую страницу табличного документа или нет. Соответственно, метод возвращает Истину или Ложь в качестве результата свой работы. А дальше, разработчик сам, «ручками», обрабатывает сложившуюся ситуацию:

На что следует обратить внимание при использовании этого метода.

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

В качестве параметра метода МассивТаблиц передается массив таблиц. Здесь должны быть указаны только те таблицы, «умещение» которых мы проверяем. Не надо забывать чистить этот массив перед следующей проверкой.

Перед помещением таблицы в МассивТаблиц, ее необходимо заполнить таблицу всеми необходимыми параметрами. Это важно потому, что одна и та же таблица может иметь различную высоту в зависимости от заполняющих ее данных.

Примечание: в качестве массива таблиц может выступать массив областей макета табличного документа.

Здесь можно скачать пример отчета на платформе 8.2, использующего эту функцию.

Читайте также: