Иерархия виджетов в U++
Содержание:
1. Реакция на события и логика программы;
2. Использование компоновок;
3.Иерархия виджетов в U++ (Вы читаете данный раздел);
4. Библиотека контейнеров NTL.
Важно понимать, что редактор компоновок не является полноценным визуальным редактором интерфейса, таким как QtDesigner или Glade. Он позволяет задать имена и относительные положения виджетов одного уровня иерархии (например, в простом диалоговом окне или на одной странице виджета с закладками) и не более того. Все свойства виджетов (кроме простейших, таких как надпись на кнопке) и логика их взаимодействия прописываются вручную в коде программы. И это не следствие лени разработчиков, а отражение идеологии U++.
Дело в том, что иерархические отношения виджетов в U++ реализованы совершенно не так, как, например, в Qt. Представим, что на форме размещен виджет TabCtrl с закладками. В Qt в классе формы определены подряд и TabCtrl, и его закладки, и все виджеты внутри закладок, невзирая на их иерархию. В Qt каждый виджет хранит список указателей на своих потомков, так что иерархия определена не на уровне классов, а на уровне самих виджетов. В U++ все наоборот. Иерархия определена исключительно на уровне классов. Каждая закладка - это отдельный класс, содержащий только виджеты, находящиеся внутри этой закладки. Сами экземпляры закладок входят в класс, унаследованный от TabCtrl, а его экземпляр в свою очередь -в класс главного окна. Пример из официальной документации позволяет лучше понять эти «идеологические различия» (http:// ultimatepp.org/www$uppweb$vsqt$ru-ru.html).
Очевидный недостаток подхода примененного в U++ - невозможность перекомпоновывать виджеты «на лету», просто меняя их предков (строго говоря, в U++ можно создавать и удалять виджеты динамически во время выполнения программы, но при этом приходится забыть о lay-файлах и осуществлять трудоемкую компоновку вручную). Очевидное же преимущество - возможность задействовать механизм шаблонов при создании интерфейса на этапе компиляции, что позволяет добиться чрезвычайно компактного и легко читаемого кода.
1. Реакция на события и логика программы;
2. Использование компоновок;
3.
4. Библиотека контейнеров NTL.
Важно понимать, что редактор компоновок не является полноценным визуальным редактором интерфейса, таким как QtDesigner или Glade. Он позволяет задать имена и относительные положения виджетов одного уровня иерархии (например, в простом диалоговом окне или на одной странице виджета с закладками) и не более того. Все свойства виджетов (кроме простейших, таких как надпись на кнопке) и логика их взаимодействия прописываются вручную в коде программы. И это не следствие лени разработчиков, а отражение идеологии U++.
Дело в том, что иерархические отношения виджетов в U++ реализованы совершенно не так, как, например, в Qt. Представим, что на форме размещен виджет TabCtrl с закладками. В Qt в классе формы определены подряд и TabCtrl, и его закладки, и все виджеты внутри закладок, невзирая на их иерархию. В Qt каждый виджет хранит список указателей на своих потомков, так что иерархия определена не на уровне классов, а на уровне самих виджетов. В U++ все наоборот. Иерархия определена исключительно на уровне классов. Каждая закладка - это отдельный класс, содержащий только виджеты, находящиеся внутри этой закладки. Сами экземпляры закладок входят в класс, унаследованный от TabCtrl, а его экземпляр в свою очередь -в класс главного окна. Пример из официальной документации позволяет лучше понять эти «идеологические различия» (http:// ultimatepp.org/www$uppweb$vsqt$ru-ru.html).
Очевидный недостаток подхода примененного в U++ - невозможность перекомпоновывать виджеты «на лету», просто меняя их предков (строго говоря, в U++ можно создавать и удалять виджеты динамически во время выполнения программы, но при этом приходится забыть о lay-файлах и осуществлять трудоемкую компоновку вручную). Очевидное же преимущество - возможность задействовать механизм шаблонов при создании интерфейса на этапе компиляции, что позволяет добиться чрезвычайно компактного и легко читаемого кода.
