Russian Qt Forum

Qt Creator 1.2.0. Создал 2 класса. ParentWindow (QMainWindow) и ChildWindow(ParentWindow)
Добавил в редакторе форм в ParentWindow кнопку, при этом в рантайме у потомка кнопка присутствует, а в дизайн режиме кнопки нет. Это баг, или мне просто хочется странного? :)

В UI для ChildWindow данных о кнопке нет, а дизайнер работает именно с UI и только этой формы а не + UI предка.
А в рантайме кнопка, поскольку она есть у предка.

Я делал ui не приват а протектед. В коде все открытые объекты включая эту кнопку видны и оступны для использования компилится нормально. Может просто я не с той стороны подхожу. Просто было бы удобно в родителе переместил/изменил контрол в родительском объекте и горя не знать. Если писать GUI руками то все замечательно работает, но редактировать интерфейс быстрее и удобнее визуально. В делфях например с этим проблем нет.

А я вообще ничего не понял. У тебя 2 формы - 2 .ui файла? Тогда один виджет можно поместить на другой только через код (.cpp). Естественно дизайнер при этом не знает ничего об отношении виджетов из разных .ui файлах. Тебе надо было при редактировании QMainWindow формы добавить на форму виджет и сделать "promote to" своему классу.

P.S.: ты случаем не Troglodit с Ogre3d сайта?

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

Я опять ничего не понял. Можешь картинку чтоль приложить?

Действительно хочешь странного. Я бы хотел бы услышать(увидеть) как ты организовываешь наследование на уровне форм :)

Есть конечно вариант это создать свой плагин для виджета(http://doc.qtsoftware.com/4.5/designer-creating-custom-widgets.html (http://doc.qtsoftware.com/4.5/designer-creating-custom-widgets.html)) но для тех целей которые ты озвучил это будет тратой времени.

Это все работает в qt на ура.Единственно неудобно это все описывать руками.
Дизайнер просто переводит xml в сишный код, то же самое можно написать руками. я это делал, НО для этого весь дизайн формы нужно представлять в голове а не на экране.Т.е. реалазация кода не проблема, просто тяжко представлять расположение элементов в форме, остальное в принципе нормально можно реализовать. Пример
Было
<ParentForm>
<OKbutton/>
</ParentForm>
Т.е. все потомки данного класса будут показывать данный баттон. А теперь нужно сдвинуть или переместить эту кнопку одному из потомков. для этого сейчас приходится руками писать изменение координат или с помощью layout'a, а с если бы данный элемент отражался бы в дизайнере, то просто сдвинуть кнопку. И это не все а просто самое очевидное преимущество.

не совсем понимаю , что еще от меня требуется чтобы объяснить. Хочу чтобы кнопка из родительского класса была возможна для изменения(переноса, изменения свойств) в дочернем классе В ДИЗАЙНЕРЕ, в рантайме все работает нормально, мне нужно знать. На форуме я прочитал есть 3 варианта подключения http://www.prog.org.ru/topic_9561_0.html может я что-то не то делаю.

В QT CREATOR'е создаю ParentForm(QMainWindow),создаю кнопку Button, далее создаю ChildForm(ParentWindow) .Я хочу добитьчя того, чтобы в ДИЗАЙНЕРЕ ChildForm была видна кнопка Button. В рантайме все отлично. Если этот пост и все выперечисленные не понятны, то даже не стоит больше спрашивать, значит я чукча. :)

Я с самого начала тебе ответил. Если не совсем понятно, напишу подругому.
Дизайнер показывает на форме только то что в ее UI. UI предка не принимаются в расчет!
Если хочешь больше пиши троллям.

2Spectre Если так, то печально, но все равно спасибо за ответ.Если б это было  я бы еще год назад начал писать на qt. :((

Человек хочет наследования на уровне форм. То есть наследование которое можно прописать прямо в DFM-ке. Это действительно есть в делфях - но на самом деле это не гуд.
Вот заголовок такой формы делфи:


А вот и нет - я сам программировал в Делфи и реализовал там несколько проектов которыми до сих пор пользуются люди. И я там использовал описанный вами способ создания интерфейса. И не только на уровне форм но и на уровне фреймов. Кутешники не зря не стали это использовать. Сначала кажется сделал форму - унаследовал от нее 10 форм - потом захотел поменять надпись на кнопке или добасить новую кнопку - делаешь это в родительской DFM - а в дочерних оно как бы само меняется. НО есть масса проблем например с именами этих кнопок - и если для главных клавиш имена часто даются осмысленные, то всякие там подкнопочки на тулбаре вполне могут называться именем данным по умолчанию - или скажем программист который работает с потомком - делая своего потомка не именует кнопочки и другие элементы интерфейса. Тогда делфи ругается, падает, ломает проект и дай бог чтобы был бекап. Набирая определенный опыт уже можно к этому придрачиться - но проблема есть сама по себе.
То есть меняя родительскую форму - не дай бог чтобы какой-нибудь "сплиттер_1" не оказался в какой-нибудь дочерней форме - которую принесет через месяц приходящий программист и прокоммитит в проект. А уж сплиттеры так вообще редко кто именует. Мне из-за этого пришлось в имени каждого компонента прописывать класс!!!! Вот это действительно длинные имена получились. И совсем неудобно - например: "AbstDBBrowser_Splitter_1".

На куте программирую уже 2 года - пока ни разу не приходилось реально использовать наследование форм!!! Так что это не должно вас останавливать - здесь есть гораздо более удобные вещи. Вообще правильнее для этих целей использовать агрегацию а не наследодвание. Потому что с наследуемыми формами бывает очень тяжело разобраться - что там от какого предка и куда. Прикиньте сами и изложите нам РЕАЛЬНУБ задачу где вы хотите использовать наследование форм. Я думаю мы дадим вам несколько спосов решения этой задачи без наследования и не менее красивым способом.

2break
не знаю насчет этих глюков, но по-моему тоже самое будет и при обычном проектировании, то что вы говорите-это совпадение имен объектов, так могло быть в любом языке программирования, это проблема ЧЕЛОВЕКА, а не языка.
Да безусловно без этого можно обойтись, вот только тогда написание , самое  главное внесение изменений становится очень трудоемкой.
А смысл чего я хотел реализовать прост, я его уже вышел писал. Создать родительские объекты (например Справочник, Документ) описать их общие свойства, методы, и ДИЗАЙН(в любом потомке можно все исправить при необходимости, но в моем случае 90% объектов не требуют больших изменений).
Напишу почему это важно. Взять 1С. Там ВСЕ объекты надо дизайнить с нуля, Даже если форма идентична один черт создавать отдельно. А теперь если нужно что либо изменить (а менять всегда что то нужно :( к слову пришлось исправлять одну программу, в которой один и тот же элемент приходил править в нескольких объектах, было бестолково потрачено куча времени) Qt большой плюс можно через компановщики сделать вполне нормальный интерфейс без дизайнера, но мне тяжко это все в голове представить.

Нет именно проблема форм делфи а не человека. Если вы еще с этим не столкнулись значит у вас был маленький опыт использования этих форм. Работать с ними можно - но это не самый лучший путь.

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

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

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

Есть еще вариант в Qt формы могут грузиться динамически и компоноваться из "запчастей" в единую форму - вот такой конструктор может и надо было бы сделать если писать "1С". При изменении запчастей все формы при следующем запуске обновятся. Для небольшой программы такой конструктор не сложно сделать.

Да и вообще использовать наследование надо там где без этого уже 100% не обойтись. То есть "реализован посредством". Про форму я бы скорее сказал что она включает в себя форму предка (агрегирует) и добавляет свои элементы а не наследует.

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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 весь интерфейс руками делать одинаково - что с ними что без них не вижу разницы - слава богу простые вещи интуитивно делаются.

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

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

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