А чего непонятного? В tutorial-примере показывается, как использовать RunBase вместе с "настоящей" формой, но при этом
- все так же добавлять поля в runtime, используя инфраструктуру Dialog;
- взаимодействовать из формы с классом, реализующим бизнес- и презентационную логику, отчасти повторяя функционал штатной формы Dialog.
Таким классом в данном случае является никто иной, как наш наследник RunBase, при этом в его методе dialog() в примере мы видим такой код:
X++:
DialogRunbase dialog = Dialog::newFormnameRunbase(formstr(tutorial_RunbaseForm), this);
Инфраструктура RunBase заточена на работу презентационной логики через инфраструктуру Dialog, и предполагается, что RunBase-у в общем случае без разницы, какая именно там форма создается, лишь бы можно было вывести на нее поля ввода и получить с нее введенные значения. Инфраструктура Dialog как раз и абстрагирует для RunBase заморочки взаимодействия с формой в части отображения исходных и получения измененных пользователем значений параметров запуска RunBase. Чтобы не нарушать эту абстракцию, в рассматриваемом примере форма создается не напрямую, а через Dialog::newFormnameRunbase().
Но раз мы затеяли собирать форму не полностью в runtime, значит, она предполагает какую-то затейливую презентационную логику и/или дизайн - "представление", одним словом (в терминах MVC). Логику мы как нормальные программисты пишем в классах, а не на формах, следовательно, форме надо иметь доступ к своему классу-"контроллеру". Таковым в случае инфраструктуры RunBase выступает все тот же наш класс-наследник, который выполняет и бизнес-логику. Но поскольку для унификации вывода и получения значений параметров он использует в качестве "прослойки" инфраструктруру Dialog, то с точки зрения формы непосредственно вызывающим ее объектом оказывается экземпляр класса DialogRunbase, а вовсе не наш наследник RunBase. Так вот, чтобы форма через класс-прослойку могла достучаться до контроллера, в этом классе-прослойке и реализован метод, возвращающий ссылку на RunBase.