boogiman.... в том числе, хорошее знание VB.
Да... Это круче китайской грамоты - практически импосибл :-).

По сабжу есть некоторый опыт -имеется собственный вариант WYSIWYG для grid-а ,
Вот здесь я уже выступал как-то
/topic/114801&pg=1&hl=zhv#927237

1) в принципе VB не понадобился – просто нужно пользовать функции Excel-а через OLE , а их удобнее отлаживать и смотреть как работают с помощью известной методы работы с макросами ;
в проекте "dw2xls" сделано круче – напрямую работа с файлом Excel-я
Надеюсь автор этого проекта Anatoly Moskovsky не обидится за повторение его ссылки
http://www.sql.ru/forum/actualthread.aspx?tid=163701&hl=zhv#1360021

2) знание формат PSR … может и не нужно. В принципе можно считать , что это примерно равно
Describe(datawindow.Syntax) + Describe(datawindow.data) . Исключение – композитные и nested отчеты – там много хитрее и геморройнее
Важно - парсить синтакс – он достаточно нагляден.
Но выяснилась странная вещь – огромная "тормознутость" строковых функций PowerBuilder – типа POS, MID… С такой скоростью для сложных datawindow (от полусотни datawindow.objects) – 10000 вызовов POS – это до десяти секунд. Пришлось писать отдельную dll-ку под API-вызов на С++ для строковых функций. Оказалось , что VC++ с PB работат глючно. Потратил время – Vatcom C++ из PB пакета версии 6.5 – нормально – разница в скорости раз в сто. Что бы это значило ?

3) проблема для free формы – нужно заниматься топологией – привязки "свободных координат" к "решетке" ячеек Excel –а . ИМХО – из-за допускаемых для DW перекрытий - иногда просто невозможно точное соответствие

4) отдельная и страшно неудобная тема – композитные отчеты . Есть относительно простой вариант грузить на разные листы Excel-a , но это не всегда приемлимо . Иначе – нужно снова заниматься расчетом топологий размещения разноформатных отчетов в единой сетке листа

В общем заказчик "простил" мне композитные отчеты – я по жизни их "не люблю" :-)

Лично меня давно интересовал вопрос - почему subj не озадачилась сама Sybase ?

Локшин МаркА Graph,N-Up,Rich Text еще делать. Graph-то тоже весьма и весьма не просто сделать... А всякие линии, овальчики прозрачности, один объект под другим. Брр....
Да забыл сказать - с графикой как таковой я вообще не занимался - не ставилась задача. В этой части - я пас. Могу предположить - что действительно - брр...

Локшин Марк
Это с таким подходом все expression'ы нужно будет самому вычислять, можно несколько хитрее сделать, да и синтаксис, опять же не документирован + полноценный парсер тоже не так просто.

Не знаю – кому как ... Два программиста – три алгоритма .
А в чем проблема сделать вот так ?

lds.dataobject = "file_name.psr"

И всё - можно отдельно извлекать синтакс и работать с данными. Выражения - как положено - через evaluate("col_name",row) . А как еще можно иначе ?

Что такое полноценный парсер ? Просто последовательно разлагаешь на лексемы строку

ls_synt = lds.Describe("datawindow.syntax")

Что надо и понятно – x,y,width, font.height,dddwname... - используешь или при необходимости модифицируешь . Что непонятно - html.valueishtml - просто не трогаешь и оставляешь как есть .

Локшин Марк ... Ну вообще-то для однозначного разложения нужно полностью знать правила построения синтаксиса DataWindow (например БНФ). Там синтаксис сделан все таки не так, как в html - нашел тэг, знаешь - обрабатываешь, не знаешь - пропускаешь.

/topic/114801&pg=2&hl=zhv#928715


автоцитата Парсится и переносится в обьект описателя datawindow строка вида
ls_syntax= dw.Describe("DataWindow.Syntax")

Хранить такую "строку" (до 80 кб) можно и в файле-шаблоне , и в базе данных … и не одну.
Она хорошо структурирована
[тип_обьекта]( [имя_параметра]=[значение или выражение]…..)

PB9 от PB6 отличается только номером в самом заголовке и наличием специальных [тип_обьекта] для выгрузку в xml и pdf. Но я такие режимы пока не ковырял - не было нужды.

Отдельно и специально - [для тип_обьекта] = table - это есть описатель datasource column .

Наверняка Sybase где-то спрятала аналогичный обьект где-то внутри private переменных - свойств datawindow . Может кто-то добрался или сможет это сделать ?

Локшин Марк Этого для однозначного разбора - мало. Такая последовательность может встретится еще до начала описания объектов отчета. Нужно знать полный синтаксис, иначе можно ошибиться при разборе, а синтаксис разный! Перевод строки в комментариях выглядит как ~r~n а в описании объекта обычным кодом перевода строки. А мало ли что там в PowerSoft'е понапридумывали. Они намудрить любят.

Мне хватило… Вроде работает

[значение или выражение] - может быть :
1) число или идентификатор (по назначению обьекта) - лексическая единица до первого пробела или скобки
2) строчное выражение – обязательно начинается и заканчивается символом (” ) - «двойные кавычки» ASCII-код 0x22 ; если внутри выражения есть необходимость разместить этот же символ – PB по умолчанию ставит перед ним маркер и записывает в строку в виде (~”) – просто нужно игнорировать это сочетание символов при поиске конца строчного выражения. Перевод строки – просто включается в выражение , за пределами лексем - игнорируется.

Распарсенный описатель datawindow раскладывается в спец.обьект с более удобными для работы структурами . После необходимых обработок или модификаций – обратный процесс – сборка строки синтаксиса из структур обьекта . После выгребания кучи огрехов – достаточно стабильно работает без видимых проблем

Локшин МаркА каким образом найти хотя бы первое вхождение [тип_обьекта]?

Проэкспортируйте и посмотрите в notepad синтаксис datawindow . Примерно так :

release 9;
datawindow(units=0 … )
header(height=136 color="536870912" )
. . . .
table(column=(type=decimal(0) update=yes updatewhereclause=yes key=yes name=is_name1 dbname="TABLE.IS_NAME1" )
. . . .
retrieve=" SELECT … "

text(band=header alignment="2" text="????" … )
. . . .
export.pdf(method=0 distill.custompostscript="0" xslfop.print="0" )


Итак первое вхождение – это всегда datawindow( …. )
Нужно выбрать и разложить всё что внутри скобок . После закрытия скобки – работа по данному обьекту закончена . Сканируем строку до следующиего обьекта – в данном случае " header" - всегда начинается с буквенного символа , символы перевода строк просто игнорирутся . Нужно учесть , что возможны вложенные описатели - главный и очень важный это table c вложенными column

Ну примерно … и так далее …

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

Что вы понимаете по словом " секция" ?
Простейшие datawidow – это freeform и grid - опция processing = 0 и 1 соответственно
Базовые обьекты это - table, header, detail, summary , footer – кажется всё .
При наличии группировок – header.N/trailer.N – шапка и подвал группы , где N – ее номер
Описатели визульных обьектов – column,compute и text . Есть еще для графики - но я их на память не помню , да и обработок над ними не делаю.

Для более экзотических типов datawindow – CrossTab,N-Up, Label – есть еще свои специфические обьекты – тоже редко приходится иметь дело , но в принципе ничего сильно выпадающего из общей логики .
Отдельно – nested и composite . Там в качестве обьекта появляется report - очень краткий описатель и ссылка на имя обьекта вложенного datawindow - и всё . Нужно искать тот обьект и парсить отдельно

Я не возьмусь утверждать точно – но каких либо условных операторов или конструкций в стиле макросов времени исполнения dw.Create(ls_synt) не попадалось

Локшин Марк Так вот, не попадалось и будет работать корректно для всех вариантов синтаксиса DataWindow - это, как говорится, две большие разницы.

Будем решать проблемы по мере поступления ТЗ и оплаты :-)

Я вообще-то не вижу жестокой необходимости в тотальном конверетере psr->xls

Таблицы - уже есть в продаже
Графики и диаграммы - лучше в pdf
rtf - в Word