Локшин МаркЧитаем про


А не проще ли про LibraryImport PowerScript function почитать?

Локшин Марк ФилиппА не проще ли про LibraryImport PowerScript function почитать?
Прочитать то может быть и проще, только зачем? Иметь динамически изменяющийся код программы, различный у разных пользователей, когда файлы - вот они лежат.

Бред какой-то.
Если использовать LibraryImport - это грубо говоря 2 строчки кода (считая dataobject assignment).
Если вашим методом делать, то это
1) Чтение файла
2) Парсание его, поскольку .srd напрямую в dw_1.Create(ls_syntax) не пойдёт (то есть пойдёт, но "датавиндова" сблюёт :-) )
3) А уж потом dw_1.Create(ls_syntax)

1) Распарсил, заодно создал, а если ещё раз этот же dataobject в этом же runе программы нужно использовать?
Опять "распарсил, заодно создал"? Вместо того чтобы его on demand сунуть в пиббл и уже иметь там и просто назначать. Говорю же - бред :-)

2) Прочитать файл по вашему - это многоступенчатый Powerscriptовый процесс (о чём я уже говорил), вместо одного системного вызова...

3) Не нравится иметь эти dataobjectы постоянно - существует LibraryDelete PowerScript function - Deletes a library file or, if you specify a DataWindow object , deletes the DataWindow object from the library. Зови её в application object's close event...

авторВот, я и говорю, по хорошему свой аналог library painter'а писать надо. А что будет если программа завершится аварийно? В pbl останется мусор? А если в это время компьютер зависнет? Останемся с кривой pbl?
Кто мешает её чистить на старте программы?
И вообще, если бы во рту росли грибы...

Anatoly Moskovsky
А вот есть еще проблема: без LibraryImport не получится использовать это DW как вложенное в композитных отчетах.
В отношении композитных отчетов эта проблема как раз разрешима и без LibraryImport :-)

Вот с nested - уже нет.

iLLer White OwlИ как можно сделать композит без LibraryImport?
Так же как и обычное ДВ. Только все нестеды должны быть уже в приложении, а вот создать нестед в композите не получится.
Глупости.

Делается это так:

1) В нормальном скомпиллированном PBD должен иметься dataobject-болванка, с какой нибудь одной колонкой, external, неважно...

Преположим нужно сделать композит с N report objects, у которых dataobjectы не существуют в пибблах...

2) Берём готовое (или через dw_1.Create(ls_syntax)) создаем datawindow, затем в нём опять же с помощью Create создаем N report objects (именуя их уникально), причём dataobjectами им всем назначаем наш "dataobject-болванка".

3) В цикле делаем GetChild на все уникально именованные N report objects и с помошью datawindowchild.Create(syntax) засандаливаем в них синтакс, сидящий в памяти (или в .srd файлах)

White OwlЗабавно, надо будет попробовать. А почему тот же самый метод не сработает для master-nested? Или datawindowchild.Create(syntax) откажется работать?

Для настоящих nested GetChild не будет работать...

White Owl Anatoly MoskovskyВложенные DW могут быть не только в композитных DW. Вот там вот и нельзя получить для них DataWindowChild - фича которую обещают разрулить в PB11 (если у меня не срабатывает ложная память:)
Ну на мой взгляд, это не фича, а полноценный баг. И его давно пора чинить...
Но, вообще-то, существует трюк позволяющий обойти эту проблему :)

Хороший баг.
Так какого же из N (равному dwmain.RowCount()) children по-вашему рецепту "исправленный" GetChild вызов будет возвращать?

White Owl Anatoly MoskovskyВот именно поэтому разработчики PB специально отключили работу GetChild в таких nested DW (а не по ошибке) - из-за неопределенности, что должна возвращать такая ф-я:
Глупости говорить изволите. nested dw по логике ничем не отличаются от группировки. Если делаешь dw с группировкой, сколько строк в группе? А? Нет, ты не спрашивай меня в какой именно группе, ты мне скажи сколько строк в группе? Точно так же и с nested dw!

Лично мне несколько раз надо было получать nested dw и вытягивать из них описания объектов. С данной задачей указаный мной трюк справляется на ура. Почему для этого пришлось трюкачить я не понимаю и считаю это в лучшем случае багом.

Anatoly Moskovskyвроде бы у всех nested метаинформация одна и та же, но наборы данных разные. И непонятно при dwc.Modify() должно ли изменение отражаться на все экземпляры или только на конкретный.
Конечно на все. Разве могут быть сомнения? Еще раз повторяю - nested dw это другой способ группировки данных. Расширить колонку - должно действовать на все экземпляры вложенных dw, добавить строку - на тот который у нас сейчас в работе. Просто как дважды-два!

Anatoly MoskovskyТак что это - 100% не баг.
Ага, только на 99.(9)% :)

Повторю ещё раз:
Так какого же из N (равному dwmain.RowCount() ) children по-вашему рецепту "исправленный" GetChild вызов будет возвращать?

Разница между обычным datawindow с dddw колонкой или там composite с report objectом и НАСТОЯЩИМ nested datawindow в том, что у composite на один report object один datawindowchild, у обычного datawindow с dddw колонкой на одну dddw колонку один datawindowchild (вне зависимости от количества рядов), а вот у НАСТОЯЩЕГО nested datawindow сколько рядов , столько и instances nested datawindows (children)

Утверждение, что nested dw это другой способ группировки данных верно с точки зрения конечного результата (чаще ввего для тех кто ленится правильный SQL написать :-), но не с точки зрения имплементации datawindow engina...

авторТак же вполне нормальным был-бы вариант добавить в GetChild еще один опциональный параметр - номер строки в dwmain. Тогда может получится что при пропуске этого параметра, после окончания dwmain.Retrieve(). Мы можем получить dw для первой строки или ошибку "строка с номером ноль" или что-то подобное.
Из всей вами написанной повести только это и имеет смысл.
Идите на ISUG и заказывайте enhancement - может для PB11 ещё не поздно...