die ui klasse zur laufzeit bestimmen [geloest]
die ui klasse zur laufzeit bestimmen [geloest]
ich hab eine klasse mit einem member namens ui. so wie das jeder kennt beim qdesigner.
problem ist jetzt aber dass ich 2 forms habe. window.ui und window2.ui ich haette jetzt gerne dass man dem fenster beim instanziieren mitteilen kann was ui nun sein soll.
window.ui und window2.ui sind fast identisch nur die layouts und splitter unterscheiden sich, werden aber von der fensterklasse nicht benutzt.
das ganze koennte ich mit templates loesen, das geht aber wegen Q_OBJECT nicht.
mir faellt sonst nichts nichttriviales ein.
euch vielleicht?
mfg qt fan
problem ist jetzt aber dass ich 2 forms habe. window.ui und window2.ui ich haette jetzt gerne dass man dem fenster beim instanziieren mitteilen kann was ui nun sein soll.
window.ui und window2.ui sind fast identisch nur die layouts und splitter unterscheiden sich, werden aber von der fensterklasse nicht benutzt.
das ganze koennte ich mit templates loesen, das geht aber wegen Q_OBJECT nicht.
mir faellt sonst nichts nichttriviales ein.
euch vielleicht?
mfg qt fan
Zuletzt geändert von qt fan am 1. November 2008 17:59, insgesamt 1-mal geändert.
dann tu das doch einfach... z.B. im Konstruktor deiner Fenster-Klasse:ich haette jetzt gerne dass man dem fenster beim instanziieren mitteilen kann was ui nun sein soll.
Code: Alles auswählen
Ui::Windows1 ui1;
Ui::Windows2 ui2;
if (x)
ui1.setupUi(this);
else
ui2.setupUi(this);
aha.. vermutlich "Single Inheritance Approach"..?
Ich würde sagen, da hilft nur ein Redesign der Software... alle statischen Zugriffe (ui.memberXy->tuwas()) raus und ersetzen durch dynamische (QWidget *memberXy = findChild<QWidget*>("memberXy"); memberXy->tuwas()).
Ich entwickle nur so... denn da ist es egal, auf welchem Weg das Objekt erstellt wurde...
Ich würde sagen, da hilft nur ein Redesign der Software... alle statischen Zugriffe (ui.memberXy->tuwas()) raus und ersetzen durch dynamische (QWidget *memberXy = findChild<QWidget*>("memberXy"); memberXy->tuwas()).
Ich entwickle nur so... denn da ist es egal, auf welchem Weg das Objekt erstellt wurde...
jain.. bei "findChild" muss halt ein QObject in was anderes (halt was es ist, ein QPushButton oder so) gewandelt werden. Aber ich würde das nur einmal machen... im Kontruktor der Klasse. Danach hast du ja alle Members immer direkt zur Hand und brauchst nichts mehr zu suchen oder zu casten...nur muss man denn memberXy immer explizit casten?
falls es dich interessiert, ich hab es jetzt mal so gemacht:
wobei ui ein uihelper ist:
jetzt kann ich auch die konvention mit ui.obj->tuwas() beibehalten.
mfg qt fan
Code: Alles auswählen
/*
* uihelper.cpp
*
* Created on: 31.10.2008
* Author: looki
*/
#include "uihelper.h"
uihelper::uihelper() {
sl << "hosts" << "chat" << "msg" << "users";
wl.push_back((QWidget**)&hosts);
wl.push_back((QWidget**)&chat);
wl.push_back((QWidget**)&msg);
wl.push_back((QWidget**)&users);
// TODO Auto-generated constructor stub
}
void uihelper::getchilds(QWidget *w) {
int i = 0;
foreach(QString s,sl) {
*wl[i] = w->findChild<QWidget*> (s);
i++;
}
}
uihelper::~uihelper() {
// TODO Auto-generated destructor stub
}
Code: Alles auswählen
if(i==1)
ui1.setupUi(this);
if(1==2)
ui2.setupUi(this);
ui.getchilds(this);
mfg qt fan
allenfalls würde ich noch passende ASSERTs platzieren:
nur damit beim Entwickeln nichts schief geht...
Code: Alles auswählen
uihelper::uihelper() {
sl << "hosts" << "chat" << "msg" << "users";
wl.push_back((QWidget**)&hosts);
wl.push_back((QWidget**)&chat);
wl.push_back((QWidget**)&msg);
wl.push_back((QWidget**)&users);
Q_ASSERT(sl.size() == wl.size());
// TODO Auto-generated constructor stub
}
void uihelper::getchilds(QWidget *w) {
int i = 0;
foreach(QString s,sl) {
*wl[i] = w->findChild<QWidget*> (s);
Q_ASSERT(*wl[i] != NULL);
i++;
}
}