Добрый вечер!

Скажите пожалуйста существует ли технология для передачи управления из скрипта своей dll-форме (если скрипт запущен из Delphi-приложения)?
Скажем для настройки параметров выполнения скрипта пользователем.
Например для выбора директории, значения из списка и/или прочекивания булевых параметров (чек и радио боксы).
Посмотрел демку с Web Forms. Почитал. Понял что эта технология не была доработана и разработчики решили от неё отказаться.

Я представляю себе реализацию таким образом:
Я загружаю модальную форму из dll-файла и передаю в неё основную нить потока выполнения скрипта. Затем, после закрытия формы возвращаю в скрипт массив параметров типа array of const (или просто массив значений типа variant).

На текущий момент, как я понимаю, существует только способ предварительного формирования ini-файла и уже последующий запуск скрипта, который будет парсить этот ini-файл и работать с полученными из него параметрами. Ну может не только так конечно (можно еще параметры предварительно сохранять во временных таблицах или в реестре).

Но вопрос именно в том чтобы передавать поток выполнения в свои, динамически подгружаемые формы и возвращать обратно с результатом выбора пользователя.

IBExpert,
Да, IBEBlock.

Про глобальные переменные я понял. В принципе думаю можно и ими пользоваться.

Я имел ввиду, например, такую ситуацию или, как модно сейчас говорить - кейс:
Сотрудник запускает скрипт, который должен загрузить множество pdf-файлов счетов, выписок, доверенностей и т.п. В ходе его выполнения нужно указать скрипту директорию из которой будут браться файлы. Затем нужно указать тип документа с которым эти файлы должны быть ассоциированы в БД (тип описан в справочнике БД и по-хорошему нужно выводить лукапкомбобокс). Затем нужно будет отметить какой идентификатор в имени файла следует искать: ИНН или Регистрационный номер. Ну и нужно ли снабжать эти файлы пояснительным комментарием (и если нужно то сам комментарий), который будет пользователям сайта сообщать какую-то важную информацию (например: "оплатить до конца месяца!").

Так вот, на этапе выбора директории уже хотелось бы запустить диалог, типа TOpenDialog и дождаться его завершения.
На стадии выбора типа открыть модальную форму с лукапкомбо со списком доступных типов ну и так далее.

Если действовать через переменные окружения, то наверное можно передавать в запустившую скрипт программу специальные метки.
Через TExecuteScriptProc2 и переданную при запуске в обработчик скрипта CallBack-функцию, например @BlockProgress, отлавливать сообщения и проверять их на наличие этих текстовых спец.меток. И если метка встретилась - запускать связанный с ней диалог, а исполнение самого скрипта пускать по бесконечному циклу, пока ожидаемая переменная окружения не примет значение отличное от дефолтного.

Но тут конечно есть риск подвесить программу.

Можно конечно заранее, перед началом скрипта запускать свой диалог и собирать все настройки, а потом их передавать через переменные окружения. И я пока остановился именно на таком варианте.

Просто когда писал очередной скрипт, подумал, вдруг уже есть какой-то хитрый способ вызывать свои диалоги/модальные формы прямо из скрипта, а я о нём не знаю)

Вот и спросил, чтобы не изобретать велосипед)

Так же, если был бы способ подгружать и открывать модально свои формы(диалоги) из скрипта, то не пришлось бы под каждый скрипт перекомпилировать основную программу. А сделать некоторое количество диалогов: выбор директории/файла, выбор значения из списка, построенного по справочной таблице, открыть текстовый редактор.

P.S.: Ну, знаете, наверное самое близкое что могу привести для примера это TfrxDialogPage в FastReporte. Ведь наверное тоже, можно было бы переменные для построения отчета собирать до его запуска, но это не так удобно, как прямо в самом отчете запускать свою модальную форму и опрашивать пользователя. Да там тоже нет TOpenDialog, но можно через OnUserFunction что угодно вызывать из скрипта отчета и ожидать ответа в потоке самого отчета без костылей типа бесконечного цикла.

IBExpert,

Я себе в идеале вижу такой подход.
У меня в базе хранятся разнообразные скрипты.
Пользователь решая ту или иную задачу вызывает запуск определенного скрипта нажав на какую-то кнопку или пункт меню.
Основная программа подгружает обработчик скриптов(IBEScript.dll), выгружает из базы скрипт и передает управление обработчику.
Обработчик в входе выполнения скрипта видит что требуется установить диалог с пользователем.
Для этого он выгружает из специальной таблицы в БД, тело указанной в скрипте dll-формы на комп пользователя и передает ей управление. Она естественно модальная. В ней пользователь что-то выбирает, отмечает, пишет - в зависимости от контекста задачи. По закрытию результат работы диалога с пользователем сохраняется в переменные окружения. Поток выполнения возвращается дальше в обработчик скрипта. Он читает соответствующие переменные окружения и передает их скрипту.

То есть у нас есть таблица со скриптами IBE$SCRIPTS, где мы храним скрипты IBEBlock.
Допустим будет такая же таблица с dll-формами. Назовем её условно IBE$DLL_FORMS. В её blob-поле IBE$FORM_SOURCE будут храниться тела dll-форм.

Зачем всё это нужно?

- Для гибкости, развития проекта, масштабирования без постоянного перекомпилирования основного Энтерпрайз-приложения, для легкости и прозрачности обновлений.

Мне удобнее большУю часть функционала реализовывать в скрипте (сбор или загрузка каких-то оперативных данных/файлов, для которых не обязательно верстать отчетные формы).
Сохраняя новый скрипт или поправив старый я моментально раскидываю его функционал на 10 разных баз типовых проектов.
В проекте при вызове каждого скрипта, приложение проверяет контрольную сумму и если она отличается грузит новую версию.
Тоже самое и с dll-формами. Тоже самое и с fastReport-отчетами.
Подкорректировать несколько dll-форм, залить их на основной сервер и с него раскидать по проектам проще, чем перекомпилировать основное Энтерпайз-приложение и выкладывать его постоянно в обновления для скачивания. Тем более, зачастую основной функционал отдельного обновления может требоваться только одному сотруднику, а качать его придется сотне.

Вот... ) Такая у меня созрела идея))

IBExpert,
Только написал последнее сообщение и увидел ваш ответ!)

авторСтандартные формы для своего приложения ты можешь и должен в своем приложении же и лепить. Я за тебя всякие формочки с комбобоксами лепить не буду, потому что это несерьезно. Сегодня тебе один комбобокс нужен, завтра пять понадобится, послезавтра чекбокс и картинку к ним добавить...

- Что вы! Господь с вами! )) Конечно же мне не нужно чтобы вы написали какие-то диалоговые формы и жестко их зашили в код IBEScript.dll!!

Наоборот )) Я бы хотел иметь возможность из скрипта загружать в память свои dll-формы и передавать им управление.

Возможно это как раз то что нужно! )) Только я пока не понимаю в каких вариантах IBEScript.dll будет ожидать ответа от приложения, а в каких нет и будет ли вообще ждать.
Если это что-то типа ibec_Progress, но только с возможностью ожидания ответа хост-приложения, то я думаю разберусь, как всё устроить )))

IBExpert,
Отлично!)

Тогда это то что нужно!))

И когда ожидается релиз, на долго нужно запастись терпением?)

<удалил дубль сообщения>

Хочу, пользуясь случаем сказать, что с непередаваемым уважением отношусь к вам и вашему делу!
Мне конечно наверное просто не с чем сравнить, так как застрял в технологии Делфи, но хочется сказать, что IBExpert это лучшая админка БД из того что мне доводилось видеть! А IBEScript существенно расширяет возможности работы с данными в стеке Делфи-firebird.
Огромное спасибо за ваш труд!!!

IBExpert ,
Огромное спасибо!

Буду изучать)

я посмотрел код примера. И у меня есть подозрение что в нём ошибка.

Чтобы её продемонстрировать нужно поменять в примере код функции DoIBEBlockUserCallback на такой:


Так же нужно заменить код блока в примере на вкладке "New Interface / callbacks" на такой:

Теперь откомпилируем, запустим экзешник и запустим пример на вкладке "New Interface / callbacks".

Когда код блока доберется до строчки


Нам нужно выбрать, например папку "Log" в директории IBExpert'a и нажать "Ок":


Мы видим что переменная в FSelDirName коде Delphi содержит корректное значение, указывающее на выбранный нами каталог:


Но затем, когда код блока дойдет до инструкции:



Мы увидим, что строковый параметр, возвращенный функцией DoIBEBlockUserCallback в исполняемый блок, содержит поврежденное значение строки:


И собственно, тоже самое мы увидим после вывода массива параметров Блока, после выполнения последней инструкции скрипта suspend:


Как это лечить.
Если в коде Делфи, в функции примера DoIBEBlockUserCallback заменить строку:


на


то проблема решается.
И теперь значение возвращаемого строкового параметра не повреждается:


<приложенный в конце поста файл скрина вторичен. приложил его по ошибке. он и так вставлен в код сообщения как ссылка на скриншот. не нашел как его удалить из этого сообщения >

Да что-то я и сам подумал об этом по дороге домой. Прошу прощения, увлёкся)
Больше не буду)

<удалил дубль сообщения. (Постил с телефона)>

IBExpert,

Спасибо!)