Операционная система QNX (в реализациях RTP 6.XX) содержит в своём составе инструментарий визуального проектирования приложений Photon Application Builder (PhAB). При всей общей приемлемости для высокопроизводительной разработки приложений для OS QNX и её графической оболочки Photon, технология использования PhAB (по крайней мере, так, как она описана в технической документации QNX) вызывает несколько вопросов:

Фирма разработчик QSSL ориентирована, в первую очередь, на использование классического языка C. Это обстоятельство часто объясняют (при чём объясняет не сама QSSL, а сторонние обозреватели) ориентацией системы на построение встроенных (embedded) систем, и, как следствие - на достижение максимальной производительности результирующих приложений.

С этим утверждением нельзя согласиться, и можно отнести его только к бытующим “народным заблуждениям”. Приложения, созданные на C++ практически ни в чём не уступают по производительности приложениям C. (Редким исключением является вызов виртуальных функций членов классов, но и здесь одна избыточная косвенность вызова может не приниматься в расчёт ввиду своей малости). По всем нюансам сравнительных производительностей этих языков, я отсылаю всех заинтересовавшихся непосредственно к анализу, произведённому автором C++ Бьярном Страуструпом, например, в двух работах, посвящённых не обучению C++, а разъяснению того, что, почему и как сделано [1,2].

Более того, GNU компилятор GCC, используемый в QNX с 2000 года, с одинаковой лёгкостью оперирует как с C, так и с C++. Приверженность QSSL классическому C (во всех их примерах использования и фрагментах кода) можно отнести только к историческим традициям фирмы с 20-ти летней историей.

И система QNX, и её графическая подсистема Photon, и GUI приложения, создаваемые с помощью PhAB, в высшей степени модульные, детерминированы и объектны. “Объектны” не в смысле используемого инструмента, а в смысле организации и функционирования. Поэтому, вдвойне огорчительно отсутствие в PhAB средств построения некоторых “крупноблочных” компонент, инкапсулирующих в себе GUI отображения и программный код, служащих повторно используемым строительным материалом для приложений.

Итак, задача: создание графических интерфейсных GUI компонент, используя IDE PhAB в операционной системе QNX RTP 6.x., с ориентацией на C++. Такие компоненты должны позволять описывать достаточно объёмные графические объекты (система связных окон, мнемосхема управляемого устройства и т.д.) с достаточно сложным поведением, и обеспечивать:

1. Создание динамических наборов (массивы, списки) единообразных пользовательских компонент в приложении;
2. Встраиваемость (переносимость) в новые приложения компонент, подготовленных в ходе более ранних работ;
3. Повторную используемость программного кода.

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

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

Class Object {

   protected:

   PtWidget_t* pFrame; 

   public:

   Object( void ) {

      pFrame = ApCreateModule( ABM_component, NULL, NULL );

      // . . . здесь делаем ещё что-либо . . .

   };

   ~Object( void ) { 

      DestroyWidget( pFrame );

      // . . . . . . . . . . .

   };

};

• Объект содержит ссылку на фрейм графического образа, отображающего объект на экране;
• Конструктор класса содержит динамическое создание (прорисовку) графического образа на экране;
• Деструктор, перед уничтожения Object, уничтожает образ его графической компоненты на экране;
• Всякое создание переменной класса Object (как локальной переменной функции, или по оператору new) будет прорисовывать графический образ на экране;
• Всякое уничтожение переменной класса Object (например, завершение порождающей функции и выход за её область видимости локальных объектов) будет уничтожать изображение образа на экране.

Из таких объектов могут строиться композиции – массивы или списки. Пример ниже описывает работу со списками (вообще, при некоторых минимальных навыках использования, динамические списки всегда более гибки, чем массивы, и я почти повсеместно использую такую структуризацию, хотя это – дело вкуса). Структура такого списка показана на рис.1:

class Element : public Object {

   friend class ElementList;

   private:

   Element* pNext;

   public:

   Element( void ) : Object( void ) { pNext = NULL; };

};

class ElementList {

   private:

   Element* pBegin;

   public:

   ElementList( void ) { pBegin = NULL; };

   void Add( Element* pE ) {

      // обычно элементы добавляются в “хвост” списка, но нас 

      // устраивает и более простой способ добавления в “голову”

      pE->pNext = pBegin;

      pBegin = pE;

   };

   PtWidget_t* FindButton( PtWidget_t* pButton ) {

      PtWidget_t *pThisFrame = GetParrent( pButton, PtWindow );

      Element *p = pBegin;

      while( p->pFrame != pThisFrame ) p = p->pNext;

      return p;

   };

};

static ElementList *pMyList = new ElementList();

for( int i = 0; i < N; i++ ) pMyList->Add( new Element() ); 

int OnButton( PtWidget_t *widget, ... ) {

   /* определяем вызвавший фрейм, в котором активизирована кнопка*/

   PtWidget_t *pWin = pMyList->FindButton( widget );

   /* выделив фрейм, требующий обслуживания,  

      выполняем над ним некоторые действия*/

   pWin->DoSomeThing();

   /* естественно, этот метод DoSomeThing вы должны описать для своего 

      пользовательского класса Object, и, так-же естественно, что только 

      автор может знать, что там в его классе нужно делать . . . */ 

}; 

Всё. Естественно – это только схема. И на первый взгляд может показаться усложнённой. Но - этот фрагмент кода, прописанный один раз, может в неизменном виде перекочёвывать из приложения в приложение. Для callback-ов других элементов контейнера component должны быть написаны соответствующие функции Find…, за образец которым может быть взята функция FindButton.

class Object {

   private:

   PtWidget_t *pFrame; 

   static PtWidget_t* getFrame( PtWidget_t* );

   static Object* getCode( PtWidget_t* );

   public:

   Object( void );

   ~Object( void );

   static int Object::OnButton( PtWidget_t *widget, ApInfo_t *apinfo,

                                PtCallbackInfo_t *cbinfo );

   void Object::OnDoSomeThing( void );

}; 

Файл “Object.cpp”:

Object::Object( void ) {

   int flags = PtEnter( 0 );

   pFrame = ApCreateModule( ABM_component, NULL, NULL );

   PtSetResource( pFrame, Pt_ARG_POINTER, this, 0 ); 

   PtLeave( flags ); 

};

Object::~Object( void ) {

   int flags = PtEnter( 0 );

   PtDestroyWidget( pFrame );

   PtLeave( flags ); 

};

PtWidget_t* Object::getFrame( PtWidget_t *widget ) {

   return PtGetParent( widget, PtWindow );

};

Object* Object::getCode( PtWidget_t* widget ) {

   unsigned long* pRes; 

   PtGetResource( getFrame( widget ), Pt_ARG_POINTER, &pRes, 0 );

   return (Object*)pRes;

};

// заголовок для callback-а сгенерированный PhAB:

int Object::OnButton( PtWidget_t *widget, ApInfo_t *apinfo,

                      PtCallbackInfo_t *cbinfo ) {

   // определяем указатель программного объекта (this),

   // соответствующего фрейму вызвавшего компонента 

   Object* pO = getCode( widget );

   // вызов метода – это главный оператор, из-за которого всё и строилось!

   pO->OnDoSomeThing();

   return Pt_CONTINUE;

};

for( int i = 0; i < N; i++ ) new Object();

class Object {

   private:

   PtWidget_t *pFrame; 

   static PtWidget_t* getFrame( PtWidget_t* );

   static Object* getCode( PtWidget_t* );

   void OnButton( void );

   public:

   Object( void );

   ~Object( void );

   static int Object::OnButton( PtWidget_t *widget, ApInfo_t *apinfo,

                                PtCallbackInfo_t *cbinfo );

}; 

Файл “Object.cpp”:

void Object::OnButton( void ) { OnDoSomeThing(); };

// заголовок для callback-а сгенерированный PhAB:

int Object::OnButton( PtWidget_t *widget, ApInfo_t *apinfo,

                      PtCallbackInfo_t *cbinfo ) {

   OnButton( getCode( widget ) );

   return( Pt_CONTINUE );

};

int OnXXX( PtWidget_t *widget, ... ) {

   OnXXX( getCode( widget ) );

}

{8,0,0L,0L,0L,NULL,NULL,"button",2009,Object::OnButton ... };

и вы снова получите ошибки сборки, всего лишь потому, что объявления класса Object (файл “Object.h”) должны стать доступны компилятору раньше, чем в файле abmain.cc появится строка #include "abevent.h".

3. Я обхожу эту проблему так: в “пустой” и не нужный теперь файл proto.h вписываю нечто типа “#include "Object.h"” для всех заголовков, содержащих объекты-компоненты. Это работает, потому, что генератор проекта всё равно вставляет ссылку на proto.h в abmain.cc. Неприятен этот способ тем, что после всякой перегенерации проекта (в ходе работы над стабилизировавшимся проектом это требуется крайне редко) - proto.h очищается. Возможно, кто-то предложит лучшее решение.

4. Ещё один полезный приём при сборке: все реализующие C++ файлы компонент (поскольку они повторно используемые, и могут включаться в различные проекты) удобно сконцентрировать в отдельном пользовательском каталоге, а не каталоге проекта, генерируемом PhAB. (Я его назову только для определённости /OBJECTY, но корневой каталог – это не лучшее место для этой цели, и Вы себе выберете более удачное месторасположение). В каталоге проекта я делаю символьные ссылки:

link /OBJECTY/Object.h Object.h 

link /OBJECTY/Object.cpp Object.cpp