Seite 1 von 1
die ui klasse zur laufzeit bestimmen [geloest]
Verfasst: 31. Oktober 2008 17:07
von qt fan
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
Verfasst: 31. Oktober 2008 17:27
von solarix
ich haette jetzt gerne dass man dem fenster beim instanziieren mitteilen kann was ui nun sein soll.
dann tu das doch einfach... z.B. im Konstruktor deiner Fenster-Klasse:
Code: Alles auswählen
Ui::Windows1 ui1;
Ui::Windows2 ui2;
if (x)
ui1.setupUi(this);
else
ui2.setupUi(this);
oder verstehe ich was falsch?
Verfasst: 31. Oktober 2008 17:31
von qt fan
ja das ist so moeglich nur sind da noch so viele andere zugriffe auf ui. ich denke es koennen auch noch mehr ui files werden.
Verfasst: 31. Oktober 2008 17:43
von qt fan
was ich auch irgendwie nich richtig hinbekomme ist eine templatefunktion mit der richtigen ui instanz als rueckgabewert.
weil da muss die fensterklasse auch wieder vorher wissen welchen rueckgabetyp es bei der funktion geben soll. und ein funktionszeiger template geht irgendwie auch nich
Verfasst: 31. Oktober 2008 17:46
von solarix
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...
Verfasst: 31. Oktober 2008 18:26
von qt fan
das klingt vernuenftig.
nur muss man denn memberXy immer explizit casten?
haette jetzt ein QComboBox object einen typdef vom eigenen typ. koennte man was basteln.
Verfasst: 31. Oktober 2008 19:07
von solarix
nur muss man denn memberXy immer explizit casten?
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...
Verfasst: 31. Oktober 2008 19:47
von qt fan
falls es dich interessiert, ich hab es jetzt mal so gemacht:
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
}
wobei ui ein uihelper ist:
Code: Alles auswählen
if(i==1)
ui1.setupUi(this);
if(1==2)
ui2.setupUi(this);
ui.getchilds(this);
jetzt kann ich auch die konvention mit ui.obj->tuwas() beibehalten.
mfg qt fan
Verfasst: 1. November 2008 10:55
von solarix
allenfalls würde ich noch passende ASSERTs platzieren:
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++;
}
}
nur damit beim Entwickeln nichts schief geht...