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

[Troglodit]

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

[spectre71]

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

[Troglodit]

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

[SABROG]

Добавил в редакторе форм в ParentWindow кнопку, при этом в рантайме у потомка кнопка присутствует, а в дизайн режиме кнопки нет.

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

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

[Troglodit]

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

[SABROG]

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

[denka]

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

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

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

[Troglodit]

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

[Troglodit]

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

[Troglodit]

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

[spectre71]

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

[Troglodit]

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

[break]

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

Код:

inherited fmAbstDBBrowser: TfmAbstDBBrowser
  Left = 314
  Top = 203
  Caption = 'fmAbstDBBrowser'
  ClientHeight = 262
  ClientWidth = 445
  Constraints.MinHeight = 250

В делфях например с этим проблем нет

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

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

[Troglodit]

2break

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

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

[break]

не знаю насчет этих глюков, но по-моему тоже самое будет и при обычном проектировании, то что вы говорите-это совпадение имен объектов, так могло быть в любом языке программирования, это проблема ЧЕЛОВЕКА, а не языка.

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

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

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

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

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

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