Я думаю, что представленный subj - это нормальная внутрифирменная технология - но не тиражный продукт.

В любой приличной программистской фирме (не только в среде PB) накапливается некая сумма наработок , опыт проектов... Затравка заложена еще в PFC - pfc_n_cst_appmanager
Насколько я понял, ребята в Combo круто заложились на динамически создаваемые окна и contol-ы. ИМХО - вопрос философский. Из своего опыта - если речь идет о не широко тиражных продуктах , т.е. для конкретные приложения для конкретных заказчиков, то необходимости в очень гибких runtime конструкторах спорна. Уж очень тонка грань, когда непрограммистское вмешательство разрушает безопасное функционирование критичных алгоритмов - у меня есть опыт "конфигурирования" 1С . Кроме того - фиксированные или типовые (к моменту сборки) диалоги и формы - проще документировать, внедрять, обучать. Исключение - т.н. "отчетники" - доступная юзеру гибкость выходных отчетных форм полезна

Тем не менее - все подобные изыски полезны - "коллективный креатив" позволил бы отфильтровать действительно интересные и эффективные решения. Не просто "как загрузить файл" - а концепции разработки приложений

Контроллер (controller) – это объект, не относящийся к интерфейсу пользователя и отвечающий за обработку системных событий, пришедших от модели. Контроллер определяет интерфейсы и методы для выполнения системных операций.
Большинство систем получает внешние события. Обычно они связаны с графическим интерфейсом пользователя. Кроме того, системе могут передаваться внешние сообщения, например сигналы от считывателя штрих кодов или кассового аппарата. Во всех случаях при использовании ООП для обработки внешних событий применяются контроллеры, обеспечивающие внешний интерфейс объектов (например, объектов окон или отчетов) и вынесение обязанностей по выполнению системных событий за пределы уровня представления

Вот по этому вопросу совершенно солидарен с авторами. Идея в том, что нетривиальную логику приложения нужно выносить с control-ов и вообще с визуальных обьектов. Очень неудобно работать, когда на какой-то кнопке или datawindow в event-е типа clicked/doubleclicked "висит" код на пару сотен строк - их иногда и не найти с первого раза - пока докопаешься до сработавшего кода в глубоком ancestor-е. А если учесть, что некая функциональность обеспечивается целым набором логически связанных window - неразумно держать исполнение этой функциональности на каком-то одном визуальном обьекте - лучше на специальном "контроллере". В общем, приложение нужно четко разделить на обьекты интерфейса, сервисов.... и совершенно определенно выделенные обьекты бизнес-логики приложения. Разделение этой логики между СУБД и PB - отдельная "религиозная" тема.

Типа дополнения к теме. Разделение понятия "контроллер" на части :

1) события по инициативе системы - т.н. event/alert-система в вариантах :
- события БД
- события сети
- события других приложений
- события внешних устройств
Реализация на базе унаследованных от timing обьектов, которые ведут сканирование соответствующих event-ов/alert-ов. Любой проинициированный пользователем диалог просто "подписывается" на нужные ему alert/event - и получает их по типовому согласованному интерфейсу сообщений

2) события по инициативе юзера - т.н. юзерский "навигатор контекста" - всякие клики, смена фокуса, ввод с клавиатруы, changeitem, tabSelect...
Простейший навигатор - master/slave, treview/datawindow. Но по требованиям изощренных заказчиков - есть навигаторы в виде комбинаций treeview,datawindow,checkbox,radiobutton, да еще на многовкладочных tab-ах - со сменой dataobject в информационных datawindow, да еще с памятью предыдущих выборов. Реализуется в виде nonvisual обьекта, который контролирует и перетаскивает "в себя" все event-ы control-ов. Причем делает это в виде "сборки" (merge) некоторой строки управления (скрипт навигатора) из всех этих юзерских деяний, которая затем парсится ("компилируется") и исполняется по всем включенным компонентам. Базовая последовательность :
- анализ необходимости и смена dataobject на datawindow
- модификация SQL операторов (особенно часто - WHERE ... ) и фильтров
- определение параметров и retrieve для datawindow
- установление согласований типа master/slave
Исполненные скрипты навигатора пихаются в стек - это обеспечивает удобный undo и rewind интерфейс - просто исполнение ранее собранных и сохраненных скриптов навигатора в обратном порядке извлечения из стека

Дополнение - специальный "терминальный" режим работы пользователя - когда нужен сверхбыстрый "машинописный" ввод заданного набора команд (с опциями) - без отрыва рук от клавиатуры на дергание мышкой. Делается на основе обьекта "команда оператора" с типовым парсером синтакиса команд и нужным количеством inherited обьектов - по конкретному набору заказанных команд. Этот же набор команд допускает их использование в режиме загрузки командных скриптов извне

3) Логи - очень эффективно для отладки и для анализа работы приложения в штатных runtime условиях

Для всех типов "контролеров" по специальным глобальным флажкам можно вести логи (можно в отдельных файлах, можно в одном). Метки времени - с точностью до 10 мс
- регистрация поступления внешних событий и реакция на них текущего приложения
- "сборка" и отработка скриптов работы "навигатора контекста"; при изощренных комбинациях "выбора пользователя" очень удобно посмотреть конкретно, как этот выбор реализуется; также очень полезны для некоторых задач оказались логирование retrieve-ов - параметры (массивы не применяются), время исполнения кол-во строк, обьем dataset...
- логирование команд оператора вообще лучше делать не в файл а в БД - это даже не лог , а "вахтенный журнал"

Ну где-то так. Вот. Поделился. Идеями. Кодом - бессмысленно. Все слишком сильно интегрированно в конкретные проекты. Документации почти нет - "из уст в уста" внутри команды.

RunmanДаже при всей гибкости и мощи Datawindow в PB, изменение структуры БД может повлечь за собой значительных усилий по модификации всех dw, которых коснется это изменение. Если бы только dw. А если ваше приложение работает на пользовательской БД, которая содержит ценную (с точки зрения потребителя) информацию - к которой вас могут и не подпустить - только в ночь с субботы на воскресенье в присутствии секурити. А если обьемы огромны - сотни гиг. Безоглядная "реорганизация" может просто убить такую базу - оцените последствия. Наглядный опыт есть - в 1С есть неплохие интсрументы, но слишком крутая реконфигурация регистров, плана счетов, справочников и т.д. требут просто интсаляции новой конфигурации и переноса данных из старой - геморр еще тот. В общем - у нас дело поставлено так, что на работающем приложении/базе - что-то добавлять еще можно, но долго и упорно обосновать необходимость такой операции, согласовать (получить добро) со всеми заинтересованными лицами... И не очень часто. Удалять или менять имена и типы - ЗАПРЕЩЕНО.

Runman Им остается только работать по определенным правилам и концентророваться на прикладной части проекта.. - я ж говорю - это порочный путь "Программирования в 1С". Скоро у вас появится штатная должность "конфигуратор PowerBuilder" - и студенты за 300 баксов вам такого наконфигурируют :)