экспорт Biff8
Что то не работает экспорт BIFF.
Ошибка "Переполнение целого", в frxCrypto модуль CryptoGetJenkinsHash
Wondows Vista, установлен Office 2003
Где бы почитать как с ним работать?
Ошибка "Переполнение целого", в frxCrypto модуль CryptoGetJenkinsHash
Wondows Vista, установлен Office 2003
Где бы почитать как с ним работать?
Комментарии
FR 4.11.4
Если в опциях проекта установть Overflow Checking=true, то появляется ошибка "Integer Overflow",
если Overflow Checking=false, то ошибки нет
Нашел несколько недоработок:
1) В русской локализации многие пункты диалога экспорта не помещаются на своих местах.
2) Смотрим файл test_b8.xls или test_b8_2.xls (это экспорт отчета через Biff8)
2.1) Высота первой строки меньше чем должна быть, в результате последняя строка текста видна только на половину.
Справедливости надо сказать, что в ole-xls такая же беда (см. файл test_ole.xls)
Очень хочется, что бы новый Biff8 экспорт в Excel, был более точен в размерах ячеек (высота, ширина), чем его предшественник (ole).
2.2) В шаблоне отчета к ReportTitle прикреплен Child. Так вот в экспорте ole-xls (test_ole.xls), Biff8 (режим объединения данных: как в отчете, test_b8.xls) одна пустая строка сразу после заголовка есть. А в Biff8 (режим объединения данных: все в одну страницу, test_b8_2.xls) пустой строки сразу после заголовка почему то нет.
2.3) Смотрим заголовок таблицы (Header) и видим, что почти все двух-строчные заголовки почему то показываются в виде одной строки с непечатным символов (квадратик) между словами, как раз на том месте, где должен был быть перенос на другу строку.
В случае же с экспорта ole-xls (test_ole.xls) такой ошибки нет.
3) Общее соображение: Будет ли работать режим объединения данных "как в отчете", если в отчете окажется несколько сотен (или даже тысяч страниц) ? Ведь наверняка на кол-во страниц в Excel есть какое то, относительно небольшое, ограничение.
ИМНО по умолчанию лучше, что бы был установлен режим "все в одну страницу".
2.1. Высота точно меньше? Я открыл отчёт в preview и xls файл в Excel и визуально сравнил по горизонтальным линиям - вроде совпадает. Другое дело, что Excel не позволяет установить высоту строки и любой многострочный текст в Excel получается выше чем в отчёте и в результате не влазит в ячейку.
2.2. Режим "всё в одну страницу" (biff8) сливает все страницы в одну и удаляет пустые строки - так задумано. Насчёт других экспортов не знаю: не обращал внимание на такие особенности.
2.3. Открыл файлы в архиве: Excel рисует тексты без квадратиков. Каким Excel-ем Вы открывали файлы?
3. При выключенном кешировании (в FR4 оно всегда выключено, потому что его там просто нет) на большом отчёте любой табличный экспорт вылетит с EOutOfResources, а при включённом кешировании (FR5) длина отчёта может быть любой. Что до ограничений Excel BIFF8, то там номер столбца ячейки задаётся двухбайтным числом и потому этот номер ограничен примерно 65,000. Возможно в более новых версиях BIFF (BIFF12 например) этот номер 4-байтный и такой проблемы нет.
Точно меньше. См. test_b8.png. На картинки хорошо видно, что 4-ая строка многострочного заголовка отчета видна только на половину. И когда в отчете таких строк много, то править их все очень долго.
Почему не позволяет ? Вот например макрос для задания высоты выделенной строки
Selection.RowHeight = 68.25
Если так и задумано это плохо. Я специально сделал между заголовком отчета и заголовком таблицы небольшую пустую строку, что бы заголовок отчета и заголовок таблицы не сливались, а biff8 взял и проигнорировал мое форматирование.
Предлагаю: Либо вообще не трогать пустые строки, особенно там где их специально сделали, либо добавить опцию которая бы регулировала такую работу.
А у меня квадратики есть. См. test_b8.png. На рисунке хорошо видны квадратики в многострочных заголовках таблицы.
Русский Excel 2003 (11.8211.8202) SP3
Ради интереса решил попробовать. Взял реальный отчет. Формат A3, альбом. В FR-Preview получилась 471 страница.
Сделал экспорт ole-xls. Получилось 15316 строк.
Сделал экспорт biff8-xls (все в одну страницу). Получилось 13441 строк.
Сделал экспорт biff8-xls (как в отчете). Получилось 470 страниц.
При экспорте ole-xls и biff8-xls (как в отчете) во время всего процесса экспорта на экране было окно-ProgressBar с описанием процесса экспорта. И после пропадания этого окна сразу становилось доступно само окно FR-Preview с отчетом.
А вот при экспорте biff8-xls (все в одну страницу) после пропадания окна-ProgressBar с отсчетом страниц, вместо отчета в окне FR-Preview, был серый фон и программа была чем то занята еще 5-10 минут и только после этого времени стало доступно само окно FR-Preview с текстом отчета.
Вообще то в этом вопросе речь шла несколько о другом возможном ограничении.
А именно о ограничении на кол-во листов в одном xls-файле.
2. Я вижу, что текст не поместился в ячейку. Я имел ввиду размер самой ячейки: он разве не совпадает с размером соответствующей ячейки в отчёте?
3. Получается средствами Excel можно изменить междустрочный интервал так, чтобы текст в заголовке поместился в ячейку?
4. 471 страница это маленький отчёт. Кеширование нужно для отчётов на 10-20 тысяч страниц.
5. Правильное замечание по поводу "серое окно на 5-10 минут": biff8 не пользуется прогресс баром. Надо будет добавить эту фичу. За эти 5-10 минут он превращал отчёт в таблицу и делал biff файл.
6. На кол-во листов тоже какое то ограничение должно быть - сейчас уже не вспомню. Но даже если оно ограничено тем же двухбайтным счётчиком (т.е. 65000 страниц), то время экспорта подобного отчёта будет огромным. Не актуальная проблема, на мой взгляд.
Ну да, так и есть. В FR-Preview многострочный заголовок отображается нормально, а в excel кусок строки не виден. То есть визуально высота строки в Excel меньше, чем она должна быть для корректного отображения многострочного текста. Вот это я бы и хотел, что бы было улучшено в экспорте biff8-xls.
А как я это могу посмотреть ? В прочем это вы можете и сами увидеть, ведь не зря же я в первом своем сообщении в этой теме в атаче приложил пример отчета t1.fr3.
Эээ, насчет межстрочного интервала я ничего не говорил. Я всего лишь сказал, что Excel с помощью своих макросов (Selection.RowHeight = 68.25) может задать точное значение высоты строки (Row). Следовательно и вы по идее при экспорте biff8 можете задать правильную высоту строки.
То есть очень важно, что бы при экспорте отчета, визуальная высота строки в excel и высота строки отчета макисмально совпадали.
Тут есть один непонятный момент: В варианте biff8-xls (как в отчете), почти сразу после пропадания окна-ProgressBar с отсчетом страниц, управление передается в FR-Preview. А в случае biff8-xls (все в одну страницу), после пропадания окна-ProgressBar с отсчетом страниц, проходит еще 5-10 минут преждне чем управление передается в FR-Preview.
Но ведь объем данных в обоих случаях одинаковый, почему же тогда такая большая разница во времени для этих вариантов экспорта ?
Ну если ограничение на кол-во страниц в xls-файле 65000, то тогда по этому пункту вопросов нет.
А что по поводу проблем, которые я описал в пункте 2.3 и в пункте 2.2 (и мое предложение по этому пункту, после ваших разъяснений) ?
Высота и ширина ячеек и так совпадают с размерами ячеек в отчёте, но из за того, что в Excel нельзя установить размер междустрочного интервала (или, как я его назвал, "высотой строки" - "line height"), получается, что многострочные тексты в Excel будут занимать больше места чем в FR и всё, что можно сделать это установить величину междустрочного интервала в FR такую, чтобы она совпадала с аналогичной величиной в Excel. Экспорт в Biff здесь ничего сделать не сможет.
Объём данных одинаковый, но сложность алгоритмов разная. В случае режима "как в отчёте" (это всё равно, что "каждая страница в отчёте в отдельный лист Excel") время экспорта линейно зависит от размера входных данных, т.е. T(n) = O(n). В случае режима "весь отчёт в один лист Excel" сложность алгоритмов которые соединияют страницы отчёта и делают другую работу уже квадратичная, т.е. T(n) = O(n^2). В FR5 с этим получше, там T(n) = O(n log(n)) для "все страницы в один лист", но всё равно на больших отчётах будет заметна разница между n и n log(n). Отсюда берутся дополнительные 10 минут.
Подведу итог:
1. Исправить "квадратики" в многострочных текстах при просмотре в Excel 2003 Rus.
2. Добавить опцию DeleteEmptyLines, чтобы можно было в режиме "все листы в одну страницу" не удалять пустые строки. Кстати, удаление пустых строк задаётся на 455-й строчке в frxExportBIFF (там написано "EmptyLines := not FSingleSheet").
3. Показывать прогресс-бар при экспорте.
А может можно при экспорте в biff8 учитывать эту разницу в межстрочных интервалах между FR и Excel и на соответствующий коэффициент менять высоту строки в Excel ? Или дать возможность задать этот коэффициент в диалоге biff8 ?
Еще один момент: похоже, что в основном визуальное несоответствие высоты строки с многострочным текстом в Excel бывает, если шрифт строки отличается от стандартного в Excel (а это Arial, 10). Следовательно можно попробовать создать расчетный коэффициент экспорта biff8 для каждого текста в зависимости от размера его шрифта.
Подведу итог: Так у вас это воспроизвелось или нет ?
Как временное решение до выхода обновленного biff8 годится.
Нельзя. Во первых это сложно сделать (нужно учитывать особенности разных шрифтов), а во вторых это неправильно, потому что изменив высоту строки в Excel сразу же изменится высота всех ячеек на той же строке.
У меня сейчас нет Excel 2003 Rus.
Например, если взять Word, то там есть возможность регулировать в свойствах абзаца междустрочный интервал, в Excel к сожалению такой возможности нет. В связи с чем есть два предложения:
1) Решить вопрос на уровне алгоритма экспорта. Это получится, если добавить в алгоритм экспорта параметр "масштабный коэффициент". Который будет регулировать растяжение отчета по вертикали. Т.е при экспорте в Excel вертикальный размер и положение по оси Y для всех ячеек отчета увеличивать пропорционально этого коэффициента. Чтобы компенсировать междустрочный интервал.
Если пользователю не важна точная геометрия отчета, но важно чтобы текст не обрезался он будет выставлять коэффициент (1.2- 1.3). Если нужны точные размеры квадратиков а многострочного текста в отчет нет то будет выставлять коэффициент 1 (единица) чтобы сохранить результат который есть сейчас. Этот коэффициент программист отчетов моет выставлять программно.
2) Решить вопрос на уровне редактора шаблона и алгоритмов генерации отчета. Реализовать параметры на уровне шаблона отчета, или на уровне каждой ячейки в отдельности. По аналогии с параметрами абзаца в Microsoft Word, сделать регулируемым междустрочный интервал, чтобы его можно было подогнать под внешний вид Excel.
Что бы FR еще на этапе генерации и дизайна отчета делал размеры и отступы текста такими как они потом должны будут получится в Excel.
PS: Можно пойти дальше, об этом я говорил на конференции в прошлом году в Киеве. Ведь FR фактически сейчас имеет две модификации дизайнере и генератора. Можно выбрать стилистику и специфику отчетов "для матричного принтера", а "можно для графических принтеров". На мой взгляд имело бы смысл сделать третий стиль отчетов, ориентированный на выдачу информации приближенной к выдачи в электронные таблицы. Чтобы при дизайне этих отчетов сразу на этапе дизайна применялась матричная разметка отчетов, без возможности наслаивать ячейки друг на друга. Чтобы потом не бороться с последствиями наслоений ячеек и неаккуратной стыковки. Интересно, что FR5 в этом отношении предложит?
и сделать подобный расчет коэффициента для них, а дальнейшем можно будет добавить поддержку расчета межстрочного коэффициента и для других шрифтов (про которые вас будут просить пользователи).
То, что сейчас в ряде случаев многострочный текст визуально не помещается по высоте в ячейку (строку) в Excel ИМНО более неправильно.
Всегда можно сделать опцию на данную фичу и пользователь уже сам будет выбирать что ему важнее - сохранение размера отчета или что бы текст визуально помещался в отведенные для него высоты строк.
То есть получается, что если я в Delphi-OI или перед ShowReport установлю в DeleteEmptyRows = False, а потом пользователь в диалоге biff8 выберет "все страницы в один лист", то моя установка DeleteEmptyRows пропадет ?
Это плохо.
В какой же тогда момент (через какое событие) я должен делать нужную мне установку DeleteEmptyRows ?
Может все же стоит добавить эту опцию и в диалог biff8 тоже ?
Подгонять параметры текста автоматически, чтобы результат экспорта совпадал с выводом Excel - тоже не лучшая идея. Наверняка при разработке такой фичи выяснится, что разные версии Excel выводят текст немного по разному и придётся добавлять в FR вместо опции "подогнать под Excel" много опций вида "подогнать под Excel 2003", "...под Excel 2010" и т.п. А потом объявятся OpenOffice с LibreOffice; выяснится, что сборка Sun ОпенОфиса выводит текст не так как сборка Novell версии 3.2.1.223.43; что сборка xxx LibreOffice добавляет один лишний пиксель над каждой буквой "к" написанной жирным шрифтом и т.д.
Я могу предложить два варианта. Первый я уже упоминал: изменить свойство LineHeight в дизайнере FR у нужных ячеек и надеяться, что результат экспорта совпадёт с ожиданиями. Второй: указать какие компоненты экспортировать в виде картинки. Минусы второго решения очевидны, но оно во первых легко реализуется для всех табличных экспортов разом, а во вторых позволяет экспортировать нужные ячейки один-в-один, правда с потерей возможности редактирования.
По поводу матричной разметки в FR5 сказать ничего не могу: я не занимаюсь разработкой этой области FR. Здесь нам нужен den.
Не совсем тогда понял о каком конкретно свойстве идет речь? Это что-то новое из FR5 или это уже есть в FR4?
Функцию с именем "LineHeight" нашел только в объекте TfrxDrawText. Полагаю это немного не то что имелось в виду.
Текст в экселе в виде картинки это кощунство
Надо же я упустил его из виду и не подозревал о его существовании. Нужно будет все наши отчеты подровнять
Вполне возможно для конкретных видов отчетов некоторое их искажение будет меньшей бедой, чем визуальное обрезание текста в ячейках Excel.
Это у кого как. Например у меня в большинстве отчетов как раз весьма много многострочных данных и почти нет картинок.
Попробовал этот вариант. Взял свой тестовый отчет (t1.fr3) увеличил LineSpace у мемки с заголовком с 2 до 4.
В этом случае в xls все экспортировалось хорошо и заголовок визуально поместился в высоту строки в Excel.
НО тут есть один существенный минус: Ведь межстрочное расстояние визуально увеличивается и в самом FR, в том числе и при печати такого отчета. И это уже выглядит не красиво, да и размер отчета тоже становиться больше.
ИМНО выход тут может быть такой: к TfrxCustomMemoView добавляем свойство LineSpaceExport. По умолчанию оно равно LineSpace. И если изменить LineSpace измениться и LineSpaceExport (но не наоборот). Соответственно свойство LineSpaceExport и будет использоваться для задания межстрочных интервалом при экспорте данных.
Не, этот вариант мне категорически не нравится. Любой экспорт (кроме графических форматов) включая и xls, должен быть максимально живым (в смысле доступным для редактирования).
то печатается нормально 1 259 627,14
а экспортируется 125 962 714. В OLE экспорте было все нормально.
В форматировании по умолчанию разделитель дроби не устанавливается и все нормально печатается
и экспортировалось, у меня куча отчетов без указания разделителя в формате.
Если разделитель не указан я так думаю, что нужно установить системный.
Сейчас срочно откатываю всех на старый экспорт.
1. Взять десятичный разделитель из мемки. Если этот разделитель не установлен, то п. 2.
2. Взять системный десятичный разделитель.
Затем убрать из текста всё кроме цифр и найденного десятичного разделителя. Всё что останется - преобразовать в число.
Если в отчёте есть мемка с текстом "123,456", а десятичный разделитель в её настройках не установлен и системный разделитель - точка, то экспорт никак не сможет догадаться, что "123,456" это 123.456
Системный разделитель целой и дробной части ","
Кидаю мемку, в мемке пишу 1234567,89
Щелкаю правой кнопкой мыши, в Форматирование строка форматирования "%g", разделитель дроби отсутствует.
На печать выводится 1234567,89
Экспорт XLS OLE 1234567,89
Экспорт BIFF 123456789
Разделитель дроби по умолчанию не устанавливается, по крайней мере сейчас, в ранних версиях не помню, в некоторых отчетах есть,
но во многих отсутствует.
Тогда и при форматировании разделитель дроби по умолчанию нужно устанавливать, я на это внимания не обратил, ну а пользователям
объяснить очень трудно: печатает с разделителями, а экспортирует в Excel без них.
02.06.2011 вышло обновление FR 4.11.8.
Были ли там какие либо изменения с biff8, которым мы обсуждали в этой теме ?
И что по поводу ответа на мое последнее сообщение в этой теме, в частности про LineSpaceExport. ?
Stalker4, я сделаю в biff8 растягивание ячеек. В обновлении 4.11.8 нету ничего из того, что здесь обсуждали.
Попробуйте задать в ячейке формат %2.2f и разделитель дроби "-" и сделать экспорт.
Допустим, в ячейке значение 311893,52
в превью видим 311893-52
в экспорте 3118-94 (хотя значение в ячейке нормальное)
Неудачная загрузка. Необходимо проверить настройки и права доступа. Пожалуйста, сообщите об этом администрации.
Прикрепил zip