Как подогнать высоту строк таблицы

[Andrew_R]

Здравствуйте!
В отчете есть таблица, заполняемая результатами запроса, и к ней "подвал" (FooterBand), высотой 92мм (он может еще и подрасти на одну строчку - до 97 мм). Заказчик потребовал, чтобы последняя строка таблицы обязательно печаталась на той же странице, что и "подвал". Это сделать было несложно - установкой свойства "Держать итог вместе"=true. Но при этом на предыдущей странице может образоваться пустое место высотой около 100мм (92 + высота последней строки), то есть около 1/3 высоты страницы. Можно ли в процессе построения изменить высоту бэнда, содержащего данные таблицы, чтобы или поместить "подвал" на предпоследней странице (чтобы она стала последней), или уменьшить пустое место на ней.
(Понятно, что такая задача возникает часто, но при поиске по форуму я решения не нашел.)

[HighAley]

Здравствуйте, Андрей.

Можно изменить высоту бэнда в событии Before Print, установив двойной проход у отчёта и выяснив необходимую высоту на первом проходе.
Более подробно мы сможем ответить увидев ваш шаблон с тестовыми данными воспроизводящими проблему.

Спасибо.

[Andrew_R]

Здравствуйте, Алексей! Спасибо за быстрый отклик.
Посылаю страницу отчета, на которой проявилась указанная проблема. Данные в рабочем отчете берутся из БД Oracle - пришлось подключение к тестовым данным (файл data.xls в архиве) переделывать. Поэтому не уверен, что все сразу заработает.

[Andrew_R]

Не дождавшись Ваших комментариев, стал экспериментировать - и наткнулся на еще одну проблему: как узнать расположение бэндов в процессе построения отчета? (Без этого настраивать высоту строк не получится.)
Если просто запрашиваю DataBand5.Top, (и Height) получаю координату и высоту, заданные в дизайнере. Еще и с какимито непонятными добавками по 4мм сверху и снизу от каждого бэнда (?) - см. test02.mrt.
Нашел на форуме тему "Вопрос по CrossTab", где шел разговор в том числе и о расположении компонентов. Попробовал сделать, как там рекомендовано:
v_exp = this.RenderedPages.GetComponentByName("DataBand5").Top;
Получил "Предупреждение при построении отчета":
DataBand5 Object reference not set to an instance of an object.
При этом переменная v_exp заполнена каким-то "мусором". (см. test03.mrt)
Поясните, пожалуйста, как сделать правильно?

[HighAley]

Здравствуйте.

Мы написали скрипт в нескольких событиях отчёта. Вы их можете увидеть в дереве отчёта.

test_modified 2.mrt

(37.61 КБ) 447 скачиваний

Пишите, если возникнут какие-то вопросы по данному отчёту.

Спасибо.

[Andrew_R]

Применил Ваш алгоритм - получилось. Спасибо. Немного потестировали его на небольших выборках, работает. В тестах использовали документы в 14..18 строк (одна или две страницы) и 46..52 строки (две или три страницы).
Поставили отчет Заказчику. А он (нехороший человек ) попробовал построить документ в 347 строк. И тут проявилась одна проблема. Строки таблицы сделаны неразрываемыми. Поэтому на каждой странице помещается чуть меньше строк таблицы, чем предполагается по результатам расчета, корректирующего высоту строки. Соответственно, на последней странице появляются "непредусмотренные" строки. В прилагаемом примере (347 строк) это вызывает появление еще одной страницы, причем с тем же самым некрасивым разрывом на предпоследней странице. Если не делать строки таблицы неразрываемыми (пока мы так это и оставили у Заказчика), то таблица поместится на 11 страницах (т.е. на одну страницу будет меньше).
Можно ли как-нибудь побороть эту проблему?

[Andrew_R]

Еще поразбирался с этой проблемой - оказалось не совсем так, как я думал.
Вы предложили округлять "добавку" к высоте строки до десятых долей сантиметра:
double inc = Math.Round(storeFS / (double)DataBand5.Count, 1);
При большом количестве строк в таблице inc оказывается равным 0 даже при заметном "на глаз" размере storeFS.
Я сделал округление до 4-го знака - стали нормально строиться документы до 900 строк. Однако при размере таблицы 1205 строк - опять та же проблема. (А у Заказчика бывают документы размером более 3000 строк - там уже "лотерея", как лягут строки.)
Возникает вопрос - до какого знака имеет смысл округлять высоту строки, если в итоге отчет преобразуется в pdf?
Или, может быть, следует искать какой-то другой алгоритм вычисления высоты строки, чтобы числитель выражения был побольше?

[Aleksey]

Здравствуйте,

Нужно некоторое время чтобы подготовить пример.

[Andrew_R]

Еще "информация к размышлению".
Я попробовал вычислять высоту строки (DataBand5) следующим образом:
x = (ph1 + (n-2)*ph) / (DataBand5.Count-1),
где ph1 - свободное место на 1-й странице (там есть "шапка" и места меньше), ph - свободное место на остальных страницах, n - общее число страниц. Count-1 - потому что последняя строка таблицы не отрывается от "подвала". Тогда при увеличении таблицы будет расти и числитель, и знаменатель выражения. Любопытно, что после присвоения Height = x и вывода Height и x в MessageBox для x выводятся 7 или 8 знаков дробной части, а для Height - всего два. Это происходит округление при присвоении (т.е. мое "округление до 4-го знака" на самом деле не работает?) или при выводе в методе ToString()?
Кроме того выяснилось, что при числе строк в таблице 1205 (может быть, и меньшем) действительно начинает играть роль неразрывность строк таблицы. При высоте строки около 8 мм на странице помещается 32...33 строки, таблица займет 36...37 страниц. По одной "лишней" строке на каждую страницу - и добавляются еще одна-две страницы, неучтенные при предварительном расчете высоты строки.

[HighAley]

Здравствуйте, Андрей.

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

Спасибо.