qtforum.de

Moin,

ich hatte das Thema vor einiger Zeit schon mal auf dem Tisch. Damals hatte ich ein Verständnisproblem mit dem englischen Text der Doku.

Ich nutze eigentlich fast immer die Mehrfachvererbung um ein UI zu programmieren. Also die GUI Klasse in der ich rumprogrammiere, erbt von der QT Klasse und von der GUI Klasse des Designers/uic. Hat den Vorteil, das ich ohne Pfeiloperator direkt auf die Elemente des GUI zugreifen kann.

Nun hab ich mich vor ein paar Tagen mit dem neuen QT Creator beschäftigt. Dort kann man ja selber festlegen, wie die GUI Klasse erstellt werden soll. Allerdings hab ich das nur bei den GUI Klassen geschafft, die nachträglich hinzugekommen sind. Wenn ich mit dem Assistenten des Creators beim neu erstellen eines Projektes auch direkt eine GUI anlege, so wird diese eben nicht per Mehrfachvererbung implementiert. Ich hab auch keine Möglichkeit gefunden, dies zu ändern.

Nun zwei Fragen:
Warum macht der QT Creator das so - gibts dafür einen Grund?
Wie - und warum gerade so - implementiert Ihr die GUI Klassen?

Martin

Ich geb meiner Klasse immer ein Member (keinen Pointer!) auf die designer-ui-Klasse. Aber nur bei größeren Sachen, bei kleinen Dialogen usw. verzichte ich auf den Designer, da code ich das händisch (geht schneller, als immer designer auf, file laden, ...).

Vorteil mit der Member-Methode liegt für mich darin, dass sofort ersichtlich ist, an welchen Stellen man auf die ui-Elemente zugreift, so ein ui.nameLabel.setText() sticht einfach im Quelltext besser ins Auge als ein nameLabel.setText(). Ist aber sicherlich auch Gewohnheit).

Beim VS Integration isses genau so ...

GUI Klassen neu erstellen -> du kannst am dialog einstellen, ob mehrfachvererbung magst

per Projectmanager nen neues QT GUI Project mit nem Mainwindow erstellen lassen, keine Möglichkeit zu waehen, sondern die Dinger werden als Member implementiert.

Designtechnisch die saueberere Loesung ist das UI als Member.
DIe mehrfachvererbungsversion hat aber den "vorteil" der autoconnects ohne ne extra methode fuer aufrufen zu muessen. was einige scheinbar auch nutzen.

Ich verwende die autoconnects ned, sondern verbinde immer immer schoen manuell. Daher nehm ich auch immer die Memberversion.

Ciao ...

RHBaum hat geschrieben:Beim VS Integration isses genau so ...

Weiß jemand wie das bei dem Eclipse-PlugIn ist?

Designtechnisch die saueberere Loesung ist das UI als Member.
DIe mehrfachvererbungsversion hat aber den "vorteil" der autoconnects ohne ne extra methode fuer aufrufen zu muessen. was einige scheinbar auch nutzen.

Ich meine irgendwo auf der QT Seite mal gelesen zu haben, das die Trolle selber die Mehrfachvererbung für die bessere Variante halten. Jeder hält das scheinbar anders.

Das es für das autoconnect bei der Member-Variante noch nötig ist eine Funktion aufzurufen war mir nicht bewusst. Da sieht man mal, das ich nur die andere Variante nutze

Martin

methusalem hat geschrieben:Das es für das autoconnect bei der Member-Variante noch nötig ist eine Funktion aufzurufen war mir nicht bewusst. Da sieht man mal, das ich nur die andere Variante nutze

Meinst du das hier: http://doc.trolltech.com/4.4/qmetaobjec ... lotsByName

genau. Du hasst slots nach ner gewissen namensconvention erstellt, und der code hat die dir dann selber verbunden ....
Musste das nur irgendwie im designer beim UI file einstellen, dann brauchte man im code gar nix selber aktivieren. Das ging aber nur bei der vererbten Sache, bei den members musste man glaub ich dann noch eine methode per hand aufrufen, dann hat er auch verbunden.
Weiss aber nimmer ob das bei 4.4 und co immer noch so ist ... wie gesagt ich nutz es eh nicht.

Ciao ...