Чтобы понять, хотя-бы в общих чертах, как же это работает, необходимо еще раз акцентировать внимание на те объекты проектирования, с которыми разработчик, использующий PowerM™, будет иметь дело. Прежде всего таким объектом является модель представления данных, информация внутри которой должна ответить на два главных вопроса: 1) что планируется отобразить на экране и, 2) в каком виде.

Как уже упоминалось ранее, статическая информация о визуальной модели сохраняется в специальной базе данных - словаре метаданных PowerM™. Каждому типу модели представления в системе соответствует свое собственное хранилище (репозитарий), редактор, а также программный класс, который унаследован от общего для всех моделей класса ViewModel. Это обычный класс с единственным отличием – создавать наследуемые от него классы, определять для них интерфейсы и связывать их работу с визуальными компонентами может только квалифицированный программист-аналитик, хорошо разбирающийся в ООП.

Для регистрации в хранилище экземпляра модели того или иного класса, необходимо выбрать в среде PowerM™ соответствующий Редактор, активировать режим создания новой записи и присвоить необходимые значения хранимым свойствам объекта. Во время "запуска" модели на выполнение (вызове специальной функции открытия модели), значения свойств будут прочитаны и соответствующим образом интерпретированы ядром системы с дальнейшим отображением результата в соответствии с заданным типом и стилем представления  модели.

Следующим шагом, разработчик может создать класс-контроллер для выбранного вида модели визуального объекта. Этот этап не является обязательным, и, более того, требуется лишь для реализации исключительно сложного алгоритма обработки системных событий. Если внутренняя, базовая логика работы модели, основанная на анализе и динамической интерпретации ее хранимых свойств и встроенных блокоа кода, уже удовлетворяет всем необходимым требованиям, никаких дополнительных классов-обработчиков для модели не требуется. Создание нового класса-контроллера практически всегда происходит через его наследование от уже имеющегося класса-обработчика с сохранением функциональности, разработанной ранее.

И последний шаг, если существует бизнес объект, методы и события которого необходимо выполнять из класса-контроллера, этот объект "прикрепляется" к модели либо в ее Редакторе, либо создается программно и используется в любом ответном событии класса-обработчика.

Таким образом, путем сцепления трех классов разного типа (визуальной модели, обработчика и бизнес объекта), получается некий самодостаточный виртуальный класс четвертого типа: комбо-класс, конкретный объект которого создается специальной open-функцией.

После инициализации объекта модели и автоматической генерации на его основе визуального компонента, последнему передается обязанность по отображению данных и приему системных событий, как внутренних, зависящих от состояния объекта модели, так и внешних, приходящих из окружающей среды: щелчки мыши, нажатия клавиш, сообщения COM-портов и т.д. Дальнейшая обработка таких событий осуществляется по цепи представление-модель-контроллер, два первых звена которой относится к уровню "ядра" системы и вмешательство в логику их взаимодействия не допустимо.

Прикладной программист может управлять поведением модели и ее представлением через события объекта-контроллера одним из следующих способов:

• Напрямую изменять свойства визуальной модели и вызывать ее методы
• Возвращать определенные значения, как результат обработки события

Любая дополнительная функциональность, при необходимости, добавляется путем создания пользовательских методов и событий в те же классы-контроллеры.

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

gnv_app.of_OpenModel( "qry://qco_product.d_product?an_group=12"),

Как видно из примера, символ «точка» является разделителем между именем класса контроллера и именем модели, а описание передаваемых параметров совпадает с синтаксисом, который используется в гиперсвязях HTML – документа (HTTP GET), а именно:

<протокол>://<URL_адрес>[?<параметр1>=<значение1>[& <параметр2>=<значение2> …]]

При открытии визуальной модели в среде Combo элемент протокол может принимать одно из следующих значений:

• qry - модель Query
• lnk - модель Master/Detail
• trv - модель TreeView
• tab - модель TabMenu
• rep - модель Report

Метод OpenModel может принимать необязательный второй параметр - текстовое описание дополнительных атрибутов команды в формате ключ-значение. Ниже приведены возможные  значения таких ключевых атрибутов:

• Parent - родитель открываемой модели (ActiveModel!, ParentModel!, GrandParentModel!)
• WinType - класс окна-подложки (Main!, Response!, Popup!)
• Role - роль  (Default!, DialogRole!). Имеет смысл только для окон типа Response! или Popup!

Таким образом, выполнить предыдущую команду с открытием окна в модальном режиме и передачей аргументу an_group значения колонки grp_id текущей гипотетической модели d_product_groups, можно следующим образом:

gnv_app.of_OpenModel("qry://qco_product.d_product?an_group=^grp_id", "Parent=ActiveModel;WinType=Response!")

Символ-квалификатор "^" обозначает ссылку на колонку (поле) текущей модели, из контекста которой создается (открывается) новая модель. При отсутствии такой колонки в текущем визуальном представлении будет сгенерировано соответствующее исключение. Возможны и другие квалификаторы, значения которых описаны далее.

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