[Qt Creator] Наследование GUI интерфейса

[Troglodit]

2break
спасибо за развернутые ответы

Реализовать то что вы говорите можно легко с помощью Qt- написать "представление справочника" (целая форма с множеством элементов), далее использовать это представление уже в кокретных справочниках, причем если форма стандартная - то можно на программном уровне оставить возможность добавления доп. кнопок на тулбар, опций меню и т.д. - можно вообще сделать чтобы они грузились из спец. файла настроек конкретного справочника. И не надо наследовать формы для добавления нескольких элементов. Естественно при изменении представления во всех кокретных справочниках мы получим желаемые изменения - скажем после замены типа "грида".

Что такое "представление справочника"?можно ссылку с примером или описанием?
наследование применяется не для упрощения добавления, а для гибкости кода, т.е. я в одном месте могу влять на все элементы родительских объектов, а не искать где это изменение нужно сделать еще. Пример с деревом некорректен, так, как вы можете создать потомка ДокументСДеревом и дальше все объекты наследовать от него, что мы получаем при этом если все эелементы мы наследуем (главный родитель) от ГлавныйЭлемент, то Все виртуальные методы этого родителя будут выполняться вне зависимости от класса потомка, а интерфейс просто побочный эффект, но тоже приятный, я утомился в разных формах когда забудешь свойство указать а потом скачешь по всем объектам и ищешь, где еще надо добавить.
ЗЫ. Про делфи повторюсь, этого не видел, скорее всего использовали кривые компоненты (тогда могут быть любые чудеса),классические версии делфи вполне стабиль и удобны для использования.

[Авварон]

я чего-то не понимаю, но ГУИ - это последнее дело? в том плане что если делать к примеру тривьюшку в пунктами и таблицу, которая отображает выделенный пункт, то в общем случае (с написанием своей модели для таблицы) времени нужно ГОРАЗДО больше, чем разместить на форме эти 2 элемента. +нужно драг энд дроп на обе и тп...

[Troglodit]

а про 2 элемента никто и не говорил. Я говорил что объекты и взаимодействие с ними делается в одном месте, при этом это можно при необходимости в помке изменить. Пример: изменение статуса документа влечет за собой изменений внешнего вида (например часть кнопок неактивные), далее определенный переход между элементами по энтреру плюс много.Все можно сделать без этого, НО если задача меняется во время разработки, или через некоторое время нужно внести изменения, а если вообще другой разраб, так это вообще ау. Я правил программу где разрабы придумали кучу велосипедов и для исправления малейшей вещи я в КАЖДОМ модуле вынужден был вносить изменения.

[Авварон]

инкапсуляция решает... я не говорю, что правильно построить программу просто, но тем не менее это нужно

[break]

По поводу "представления справочника" - первый вариант который приходит на ум с Qt (не факт что самый лучший, но думаю имеющий право на существование)

1) Рисуем в дизайнере форму "Табличный справочник" - получаем ui файл в котором есть тулбар, грид, и др. элементы
2) Делаем CPP класс формы стандартным для Qt способом и динамически загружающим этот ui файл - класс формы ищет в ui-шнике все необходимые контролы и запоминает указатели на них. То есть он может управлять таблицей, ловить события от нажатий кнопок и т.д.
Собственно этот класс реализует всю функциональность справочника. - Добавление записей, фильтр, удаление и т.д. Если необходимо в нем будет работать своя написанная модель и т.д. Скорее всего если речь идет о БД то в базовом классе ведется вся работа с еще неизвестным именем таблицы - она установится в конкретном наследнике.
3) Потомки этого справочника - уже конкретные справочники программы могут посредством кода добавить свои кнопочки и некоторые другие элементы интерфейса на уже свою форму (тот же загруженный ui). Как я говорил это может и не очень удобно по сравнению с наследованием в дизайнере и дорисовкой элементов там - но если изменения не значительные, например доп. кнопки тулбара или пункты контекстного меню, то вполне норм. А если справочник значителдьно меняется - то и наследование форм не поможет, т.к. при таких перегруженных перенаследованиях в одном из потомков когда-то окажется излишнее неиспользуемое количество контролов.

При этом если родительский ui будет перерисован - или заменен тип элемента, естественно во всех дочерних эта подмена произойдет. Правда с изменением типа элемента также прийдется внести в коррективы в базовом классе формы - если этот элемент там используется. Загрузку из ui можно не делать - но с ней теоритически можно с одним управляющим классом связать несколько внешних видов окна справолчника. В реальности все сильно зависит от конкретной задачи.

По поводу стабильности Delphi - может сейчас я не прав - последние версии с которыми я работал были 2005 и 2006 - это было очень страшно - они вылетали по 3 раза за час. Они у нас были лицензионные поэтому начальство заставляло пользоваться. Дома я использовал Delphi 7 - она для меня была самой стабильной.

[Troglodit]

2break
дело в том что по умолчанию ui-переменная в классе приват, т.е. к ней обращение из потомков невозможно, т.е. ,например,изменить метод при нажатии на кнопку уже не получиться, пока не ui не сделать protected.Далее, добавлять кнопки в дизайнере для потомков, не видя остальных элементов бред, проще в коде их добавить, но при условии, что ui protected иначе смысл в потомках вообще теряется.Пока решил разобраться с лейоутами и писать все руками,но все же имхо способ из делфей очень удобен для создание темплейтов для практически подобных элементов.
Насчет делфи я и пbсал на 7 имхо классика, остально уже или устарело или беcпочвенно навороченно.
ЗЫ. Не совсем по теме топика, но подскажите пожалуйста насчет SQL модели для TreeView что-нибудь изменилось. С год назад получалось для каждого дерева нужно было руками писать SQL модель самому, даже если она отличалась всего лишь названием sql таблицы или мож я что не так понял?

[break]

Далее, добавлять кнопки в дизайнере для потомков, не видя остальных элементов бред, проще в коде их добавить, но при условии, что ui protected иначе смысл в потомках вообще теряется.

Я вроде об этом и говорил - на счет приват или не приват - это дело каждого можно сделать inline функцию которая вообще будет в публик указатели на нужные виджеты возвращать или на весь ui;

Как вы это замените лейаутами - не понимаю - можно по подробней?

На счет вашей SQL модели - кто вам мешает сделать ф-цию setTableName - и использовать одну модель для всех деревьев???

[Troglodit]

2break можно поподробней про inline я не понял вообще.
Лейаутами просто руками делать интерфес,я уже начал пробовать, гораздо удобнее оказалось (например так и не нашел в дизайнере как добавить кнопку в тулбар, а руками все отлично получилось),при этом можно сделать все как я и хотел с наследованием свойств и методов визуальных элементов, просто я точно знаю что в моем случае будет очень много похожих по дизайну окон. Не буду ничего утверждать я в qt нуб, но мне кажется так будет удобней, получаю гибкость в коде управления объектами.

[denka]

например так и не нашел в дизайнере как добавить кнопку в тулбар, а руками все отлично получилось

Для этого в дизайнере есть Action Editor


З.Ы. Плохо видать искал я дизайнером в 4-ке почти не пользовался, но нашел за 2 минуты

[break]

Код

C++ (Qt)
class CBaseForm : public QWidget
{
	Q_OBJECT;
	Ui::BaseForm m_ui;
public:
	CBaseForm(QWidget *parent = 0);
             inline Ui::BaseForm * getUI() { return &m_ui; }
             inline QTableView * dataGrid() { return m_ui->dataGrid; }
........
}

Лейаутами просто руками делать интерфес,я

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

[Troglodit]

2break
Спасибо за разъяснение.
А в чем будет раница

Код:

inline Ui::BaseForm * getUI() { return &m_ui; }
Ui::BaseForm * getUI() { return &m_ui; }

?

[Авварон]

inline говорит по возможности использовать ф-ию как макрос, подставляя  код напрямую.

[Troglodit]

спасибо всем за ответы.