die ui klasse zur laufzeit bestimmen [geloest]

[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

[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?

[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.

[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

[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...

[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.

[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...

[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

[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...