Доброго времени суток.

Не первый день уже сижу над этой проблемой...

Имеется кросс (2 ColumnLevels, 3 RowLevels, 1 CellLevel). Данные 2го уровня (т е 1го индекса) столбцов содержат ...ну, очень длинные названия. При этом данные первого уровня строк содержат не очень длинные названия. Все остальные данные заголовков содержат относительно короткие обозначения.

В Cells содержится строка, недлинная (всегда состоящая из 2 строчек(формируется в запросе)): длиной от 3 и до 6-7 символов.

А, да, еще: страница бесконечна(ибо кол-во столбцов заранее неизвестно) + у кросса AutoSize = true.

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



На этом изображении MaxWidth у кросстаба не ограничен (т е почти не ограничен = 5000). Поэтому все названия "расползаются" на всю ширину. Для тех данных, что в первом столбце (т е для нас это RowField[0]), такая ширина вполне приемлема, а вот для тех данных, которые в третьей строке заголовка столбцов ( т е ColumnField[2]), это абсолютно неприемлемо, потому что отчет со всеми данными "расползается" в бесконечность, и выглядит вот так:


(это изображение просто, чтоб было понятно, что на напечатанном листе данные нечитаемы)


Если попытаться ограничить ширину столбцов, то сужаются абсолютно все столбцы. И первый (тот, что, как правило, содержит не оч длинные названия тоже).



Тогда форма становится читаемой, но пользователи не понимают, зачем нужна "такая высокая" строчка для данных с названием "Название длинное 7". + разумеется, эти самые названия могут быть разной длины для разных баз данных.

Вот как выглядит форма, если MaxWidth = 60


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



И, конечно же, мы получаем умные предложения от пользователей типа: "Вы бы первый столбик немножко расширили, и форма поместилась бы на 1 страницу, а то нам бумагу экономить надо"....


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



А при большом кол-ве столбцов форма сжимается по вертикали:


Эта схема в общем-то работает (ну, если не считать некоторой погрешности в вычислениях, когда именно переносить названия данные столбцов 2го уровня, особенно при нестандартных форматах, типа А3)

Но...сейчас появилась необходимость добавления еще одного уровня столбцов. Делается это динамически (и лишь для определенных наборов данных).
И тогда отчет выглядит несколько иначе:


И работающая схема с вручную посчитанными переносами части строк в столбцах 2го уровня перестает работать, ибо для некоторых из столбцов названия не нужно делить вручную на несколько строк.

Были попытки посмотреть в сторону вертикальных бэндов, но, если честно, не совсем разобралась + в этом отчете в шапке сверху используется вложенный отчет, а с вертикальными бэндами это вложенный отчет работать перестал.

Может, кто-нибудь уже сталкивался с похожей проблемой? Заранее премного благодарна.

DimaBrНе использовать Кросс.
Ок. Что использовать?

DimaBr,
Не могу ((((
Форма стандартизованная.... Пользователи не поймут

gpiУстанавливайте ширину столбцов кросса в событии кросса OnCalcWidth
Уже пробовала...Но...
OnCalcWidth срабатывает перед выводом КАЖДОГО cell (НО НЕ row или column) и просто-напросто обрезает все данные, которые в ячейку columnа не вместились.



Уже пыталась так делать (((( У меня тоже так сделать - была первая мысль. Но спасибо за идею )

OlyaLoraкоторые в ячейку columnа не вместились
вместо того, чтоб "растянуть" ячейку вниз

DimaBrОтчёт не должен ФОРМИРОВАТЬ данные, он должен их печатать из датасета (ну итожки конечно не в счёт)
Он их и не формирует. Даже если, предположим, убрать динамическое создание колонок (которое, кстати, появилось лишь только из-за того что РАЗНЫЕ строки датасета Fast воспринимает как одну и ту же из-за совпадения части ключа) и оставить жить два разных макета (чего бы тоже не очень-то и хотелось, ибо при изменении одного макета необходимо будет непременно помнить об изменении и второго), то мы вернемся к предыдущей схеме, т е "ручному" управлению расстановок символа конца строки в данных, что тоже нехорошо и некрасиво, потому что по-хорошему, я не знаю, как правильно посчитать, после какого именно символа ставить конец строки для оптимального вида печати (да и сдается мне, не должна об этом задумываться, потому что, как раннее написал gpi, OnCalcWidth должен посчитать это и без меня, коль скоро отчет в этом случае данные ни коим образом не формирует).

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

gpiПопробуйте, поможет ли MaxWidth в этом случае. А ширину column (4 и далее) мoжно задавать и в OnCalcWidth
Да тоже уже пробовала. Обрезает длинные названия. Причем степень "зарезания" зависит от выставленной MaxWidth.

Отчет с MaxWidth = 100, а в OnCalcWidth ширина = 60 (заголовки 7 и 8 столбцов обрезаны, но не сильно (хотя, думаю, определение "не сильно" вряд ли устроит пользователя))


А вот отчет с уже MaxWidth = 200, а в OnCalcWidth ширина = 60 (заголовки 7 и 8 столбцов обрезаны, и уже прям сильно)


А это отчет с уже MaxWidth = 500, и нет OnCalcWidth (заголовки 7 и 8 столбцов не обрезаны, но зато и форма нечитаема)

Можно, конечно, каким-то образом попытаться вычислить оптимальное соотношение величин MaxWidth и Width в OnCalcWidth, давая fastreportу возможность "обрезать слишком длинные" с его точки зрения данные, но мы-то знаем, что это нехорошо, и пользователям вряд ли понравится....
Уверена, что первое, что услышу будет:"Просто сделайте ячейки с названиями подлиннее" )))

vavan,
Попытаюсь сейчас поискать.

Тикет, кстати открыт до сих пор. А прошло уже почти 4 года ))))



Но и не решен

чччДЧто вы так уродуетесь, выводите в иксель
Отчету не один год. И он работает.

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

gpiПример для FRDemo. FR 5.6.14
Эммм...мы с Вами, наверное, не оч друг друга поняли. Вот чуть переделала макет. Кстати, почти такой же я отправляла и ребятам из фаста.

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

DimaBrВаш Кросс данные не суммирует ?
Пока, да. Не суммирует. Но это не значит, что завтра это не понадобится ;)


DimaBr У вас проблема в формировании заголовка колонок ?
Именно. Точнее, проблема в формировании заголовка, влезающего на страницу таким образом, чтоб всё было максимально читаемым.

DimaBrЗачем пытаться использовать Кросс, если количество колонок заранее известно ?

Оно НЕИЗВЕСТНО заранее. Варьируется от запроса и от базы. от 1 и до....ну, порядка 50ти точно встречала. Известно оно мне будет только тогда, когда запрос выполнен. Для каждого из запросов (и в каждой отдельно взятой базе данных) количество колонок будет разным

DimaBrСоздайте мемки на бенде Header или ColumnHeader, сделайте его растягиваемым и мемки растягиваемыми.
Зная количество колонок в датасете, можно получить ширину колонки, создать мемки на Detail-бенде и на Header-бенде.

Я правильно поняла, что мемки нужно будет создавать динамически? (кол-во колонок-то неизвестно)
В общем-то, меня это не пугает, просто не уверена, что это наиболее оптимальный способ решения. Если уж создавать всё руками, то проще действительно писать сразу в excel

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