Читаем про

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

ФилиппБред какой-то.
Да похоже.
ФилиппЕсли использовать LibraryImport - это грубо говоря 2 строчки кода (считая dataobject assignment).
Да?
ФилиппЕсли вашим методом делать, то это
1) Чтение файла
А для LibraryImport файл уже читать не нужно?
Филипп2) Парсание его, поскольку .srd напрямую в dw_1.Create(ls_syntax) не пойдёт (то есть пойдёт, но "датавиндова" сблюёт :-) )
Парсить - это здесь только одно название. Выкинуть первую строчку.
Распарсил? Заодно и DataWindow создал.
А по поводу сблюет - только лишнее свидетельство недальновидности (мягко выражаясь) авторов PB.
Филипп3) А уж потом dw_1.Create(ls_syntax)
И что мы имеет? В результате в вашем случае мы имеем лишнее действие - затягивание файла в библиотеку. В моем парсение синтаксиса (первую строчку, кстати, можно просто пропустить при чтении файла). Далее, когда набор DataWindow лежит в виде файлов, то от легко управляется любым броузером файлов и не привязан к программе. Затягивая это все хозяйство в библиотеку, мы имеем проблемы при обновлении версий (эту библиотеку ни в коем случае не накрывать другими версиями), переносе DataWindow из одного места установки программы в другой (объединение набора DataWindow из разных мест). Плюс ко всему, имеем неприятные особенности, связанные с PowerBuilder'ом. К примеру - необходимо контроливорать размер библиотеки (по крайней мере в PB6 при больших размерах библиотеки с вероятностью ~50% билдер при сохранении разрушал библиотеку - убеждался на личном опыте). Несколько раз в PB 9 при сохранении DataWindow после этого приходилось править руками синтаксис, т.к. криво сохранял. Один раз наблюдал сохраненное окно... но скрипты куда-то пропали.
Так что мы уж лучше доверим это дело файловой системе, благо она более надежна.

ЗоринАндрейЭта строка кода (мягко выражаясь недальновидно ) не учитывает наличие комментария к объекту.
:( Согласен. Лучше искать char(10) + "release"

ФилиппОпять "распарсил, заодно создал"? Вместо того чтобы его 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? Нужно придумывать схему для задания уникальных названий DataWindow - а вдруг datawindow с таким именем уже есть, что тогда будет? Не нравится каждый раз считывать? Кэшируйте в памяти, сохраняя синтаксис DataWindow. Ваш метод с LibraryImport несет в себе лишь одни проблемы, перечисление которых можно продолжать. Единственная проблема, моего метода - это недокументированность формата *.srd