Классы для генерации отчетов в Excel

[tolstjak]

Цитата:

Сообщение от tolstjak

ОК.
так и сделаю.

Сделал.
Все заработало. Но почему-то стала не симпатичная форма "Генерация отчета". Раньше отображался красивый принтер, а теперь одна строка и то с нулем.
Где это можно поправить?
Заранее благодарю.

[Eldar9x]

Цитата:

Но почему-то стала не симпатичная форма "Генерация отчета". Раньше отображался красивый принтер, а теперь одна строка и то с нулем.

А зачем он, в смысле принтер? Я его снес, по соображениям производительности. К тому же без него круче смотрится . Но если уж хочется, делается просто:
Открываете метод new() класса CXMLExcelReportEx. После строки prg.setCaption(#PRG_CAPTION);
пишете prg.setAnimation(#AviPrint);

[tolstjak]

Цитата:

Сообщение от Eldar9x

А зачем он, в смысле принтер? Я его снес, по соображениям производительности. К тому же без него круче смотрится . Но если уж хочется, делается просто:
Открываете метод new() класса CXMLExcelReportEx. После строки prg.setCaption(#PRG_CAPTION);
пишете prg.setAnimation(#AviPrint);

Понял. Спасибо.

[propeller]

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

Строка меняет цвет, текст становится жирным, но в тех ячейках где числа - никаких изменений.
Делал свой стиль для числа - не помогает.

Можно ли числовые ячейки форматировать?

[Eldar9x]

Цитата:

Сообщение от propeller

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

Строка меняет цвет, текст становится жирным, но в тех ячейках где числа - никаких изменений.
Делал свой стиль для числа - не помогает.

Можно ли числовые ячейки форматировать?

Конечно. Просто нужно было конкретно для числовой ячейки указать, нужный стиль:

    CExcel excel = new CExcel();
    ;

    excel.send(["Строка", 10.0], ["CLR_BOLD_STR", "", "CLR_NUM"]);
    excel.show();

Иначе, если в ячейке находится число, то берется DEF_NUM.
Ну другой вариант так делать, только тогда формат ячейки эксель будет 'общий',а не числовой:

    excel.send(["Строка", strfmt("%1", 10.0)], ["CLR_BOLD_STR"]);

Во вложении новые классы. Объединил оба класса в один. Вместо CXMLExcelReport и CXMLExcelReportEx. Избавился от класса интерфейса. RunBase классы тоже по идее не нужны, только путаница лишняя. Обратите внимание на макрос AX4 (надо определить, если выше 4ки)

[gl00mie]

Цитата:

Сообщение от Eldar9x

Обратите внимание на макрос AX4 (надо определить, если выше 4ки)

В теме #ifdef.ax4 предлагалось готовое решение для условной компиляции, учитывающей версию Аксапты.

[gl00mie]

К слову, в коде метода xmlStart() зашита строка

"<?xml version=\"1.0\" encoding=\"WINDOWS-1251\"?>\n"

однако, при работе в 4-ке и выше сформированная строка будет вовсе даже не в ANSI-кодировке.

[Eldar9x]

Цитата:

Сообщение от gl00mie

В теме #ifdef.ax4 предлагалось готовое решение для условной компиляции, учитывающей версию Аксапты.

Видел, но там ведь только 3ка и 4ка...
Мне кажется, легче самому контролировать.

Цитата:

однако, при работе в 4-ке и выше сформированная строка будет вовсе даже не в ANSI-кодировке.

Не совсем понял... а в чем будет проблема?

[gl00mie]

...Ну так просто: в XML будет прописана кодировка ANSI, хотя сам XML будет в UTF-16; в принципе, мелочь. Однако, применительно к 2009-й у вывода в Excel большого куска данных в XML обнаружился еще один "побочный эффект": в ядре реализовано ограничение на максимальный размер памяти, который может быть выделен одной сессией под переменные кода Х++. Если код попытается собрать слишком длинную строку, больше примерно 4-5 Мб, то вылетит ошибка времени выполнения "недостаточно памяти для выполнения скрипта". Можно настроить тот же AOS, чтобы у него не было такого ограничения, но это не спасет, если с AOS'а попытается передать такую длинную строку на клиента - вылетит точно такое же исключение. Соотв., в общем случае надо настраивать и AOS, и клиента, однако, засада в том, что клиентов может быть много, и настройку они могут читать из HKCU, так что надо по идее на каждом хостев каждом профиле прописывать в реестре настройку, снимающую ограничение на максимальный размер буфера (что именно прописывать, рассказывается в заметке Error executing code: Insufficient memory to run script в блоге EMEA DAX Support). Если клиенты запускается с определенным конфигом, да еще и лежащим где-нить на сетевой шаре, тогда проще - можно просто подправить этот конфиг и все. Но факт тот, что оперирование большими текстовыми буферами требует "тонкой настройки" сервера и клиента.

[Eldar9x]

Цитата:

Сообщение от gl00mie

...Ну так просто: в XML будет прописана кодировка ANSI, хотя сам XML будет в UTF-16; в принципе, мелочь. Однако, применительно к 2009-й у вывода в Excel большого куска данных в XML обнаружился еще один "побочный эффект": в ядре реализовано ограничение на максимальный размер памяти, который может быть выделен одной сессией под переменные кода Х++. Если код попытается собрать слишком длинную строку, больше примерно 4-5 Мб, то вылетит ошибка времени выполнения "недостаточно памяти для выполнения скрипта". Можно настроить тот же AOS, чтобы у него не было такого ограничения, но это не спасет, если с AOS'а попытается передать такую длинную строку на клиента - вылетит точно такое же исключение. Соотв., в общем случае надо настраивать и AOS, и клиента, однако, засада в том, что клиентов может быть много, и настройку они могут читать из HKCU, так что надо по идее на каждом хостев каждом профиле прописывать в реестре настройку, снимающую ограничение на максимальный размер буфера (что именно прописывать, рассказывается в заметке Error executing code: Insufficient memory to run script в блоге EMEA DAX Support). Если клиенты запускается с определенным конфигом, да еще и лежащим где-нить на сетевой шаре, тогда проще - можно просто подправить этот конфиг и все. Но факт тот, что оперирование большими текстовыми буферами требует "тонкой настройки" сервера и клиента.

А, ну так это решено:

Классы для генерации отчетов в Excel

Цитата:

1) Добавлена возможность контролировать (без перегрузки метода) предельный размер буфера до выгрузки (swapQty). по умолчанию выставлено в 1000;
X++:
report.swapQty(1000);
2) Добавлена возможность контролировать размеры буфера во избежание его переполнения:
задается командой
X++:
report.autoSwap(true);
по умолчанию выключено
макимальный размер буфера (по умолчанию выставлен 1000000) задается командой
X++:
report.maxStr(1000000);
Это гарантирует работу при любом размере отчета, но несколько замедляет его вывод, поэтому при большом числе колонок лучше регулировать swapQty.

Кстати, проблема эта не только в 2009, а как минимум уже в 3ке уже есть.