Wie in, von Qt erzeugten, ui.h Dateien debuggen

[Boron]

Wenn ich im Qt-Designer einen Dialog bastle und alle Slots in der ui.h Datei implementiere, wie kann ich dann diesen Code debuggen.

In meinen Projekt in KDevelop habe ich logischerweise die dialog.ui in mein Projekt aufgenommen. Der User Interface Compiler arbeitet auch problemlos, ich kann also meinen Dialog wunderbar in meinem Programm benutzen.

Allerdings funktioniert im Dialog irgendwas nicht so wie ich es mir vorstelle, also ist debuggen angesagt.
Dazu habe ich die dialog.ui.h (in der aller Code steht der in meinem Dialog beötigt wird) auch in mein Projekt aufgenommen, und an die verdächtigen Stellen Breakpoints gesetzt.

Wenn ich jetzt allerdings den (KDevelop internen) Debugger starte, dann werden die Haltepunkte völlig ignoriert, obwohl der Code 100%ig ausgeführt wird (nachgeprüft mit einigen cout Anweisungen).
Wie kann ich ui.h Dateien debuggen?

[anda_skoa]

Meistens ist die Ausgabe von Debugoutput an ausgeuschten Stellen viel effektiver als das Schrittweise ausführen in einem Debugger, vorallem bei GUI Anwendungen.

Eventuell gibts beim Breakpoint setzten Komplikationen, weil eine .ui.h Dtei kein Header sondern eigentlich einen CPP Datei ist, die aus schwindligsten Gründen .h genannt wurde (aber keine Header Eigenschaften hat)

Ciao,
_

[Boron]

Meistens ist die Ausgabe von Debugoutput an ausgeuschten Stellen viel effektiver als das Schrittweise ausführen in einem Debugger, vorallem bei GUI Anwendungen.Das mag wohl sein (und so muss ich das jetzt im Moment auch machen), aber das muss ja wohl nicht bedeuten, dass ich nicht normal debuggen kann.
Eventuell gibts beim Breakpoint setzten Komplikationen, weil eine .ui.h Datei kein Header sondern eigentlich einen CPP Datei ist, die aus schwindligsten Gründen .h genannt wurde (aber keine Header Eigenschaften hat)Trolltech hat ja in der Designer Doku ein paar Argumente drin (wie du sagst, schwindlig), warum das eine .h-Datei ist. So richtig hat sich mir der Sinn nicht erschlossen. Wenn es mich allerdings davon abhält zu debuggen, dann werde ich böse :mad:. Wie stehen die Chanchen, dass Trolltech selbst eine vernünftige Antowrt parat hat?
Gibt es echt keine Möglichkeit darin zu debuggen?

[tuxipuxi]

Hi,

den ui.h Ansatz finde ich sowieso schlecht und finde, dass er zu hässlichem code führt.
Wieso subclasst du nicht lieber die uic generierten Klassen?

Michael.

[Boron]

Wieso subclasst du nicht lieber die uic generierten Klassen?Gute Frage! Da war, glaube ich, was in der Designer Doku was mich dazu brachte mich für die ui.h Variante zu entscheiden.
Ich wüsste zwar nicht warum der Code deswegen hässlicher wird, aber er ist halt irgendwie nicht da wo man ihn erwartet.

Ich denke ich werde ableiten.

[edit]
Was soll denn das jetzt wieder :confused:?

KDevelop, oder der uic, oder sonst wer, erstellt mir keine Implementierung mehr für die Basisklasse. Also den Teil, in dem das komplette Layout für mein Dialogfenster erstellt wird. Ohne diese Implementierung ist aber Ableiten völlig sinnlos. Die glauben doch nicht etwa, dass ich jetzt das Layouting selbst übernehme?

Wie kann ich KDevelop dazu bringen, dass er mir sowohl Header als auch cpp für meine Basisklasse des Dialogs erstellt?

[Boron]

Help :eek: und mal ganz frech *hochschieb*, wegen [edit] oben.

[anda_skoa]

Eventuell musst du die Makefile Generierung neu veranlassen.

Ist das ein automake oder ein qmake basiertes Projekt?

Ciao,
_

[Boron]

Alles läuft über automake. Ein KDevelop Template halt.

Aber eigentlich habe ich doch das Makefile schon mal neu generieren lassen?
Distclean und rebuild aus dem Menü.

[anda_skoa]

Hmm.
Schau mal ob das .ui File bei den Projektdateien dabei ist.

Kann mich erinnern, dass es da unter KDevelop2 drinnen sein musste.

Ciao,
_

[Boron]

Die dialog.ui ist definitiv dem Projekt hinzugefügt und wird auch korrekt im dem Dateibaum (wo auch Header und Sourcen drinstehen) als User Interface Datei angezeigt.

Ich habe jetzt mal ein komplett neues Projekt aufgesetzt und alle nötigen Dateien (*.h, *.cpp und *.ui) übernommen. Es zeigt sich keine Änderung im Vergleich zu dem bisherigen Projekt. Es wird weiterhin keine Implementierung zu der Dialogbasisklasse erstellt.

Es ist zum kotzen *seufz*.

[anda_skoa]

Erstelle mal .h und .cpp mit dem UIC manuell und füge die auch dem Projek hinzu.

Also
uic -o baseclass.h baseclass.ui
uic -o baseclass.cpp -i baseclass.h baseclass.ui

Ciao,
_

[Boron]

Ich habe rausgefunden an was es lag.

Nehmen wir an, dass in meiner Basisklasse DialogBase sich ein QPushButton befindet.
Ich leite jetzt die Klasse Dialog von DialogBase ab, und ich möchte im Konstruktor von Dialog den Text des Buttons ändern, also button->setText("gaga").
Der Compiler brachte dabei immer die Meldung "first time use setText()".

Das Problem war, dass in der dialog.h eine Methode der Klasse QPushButton aufgerufen wurde, der Compiler aber nicht wusste welche Methoden QPushButton anbietet.
Lösung: In dialog.cpp habe ich ein #include <qpushbutton.h> eingefügt. Jetzt wird vom uic auch die Datei dialogbase.cpp erstellt und alles ist in Butter.

Wer dieses Gelaber jetzt verstanden hat und nachvollziehen kann hat meinen Respekt verdient :D. Jedenfalls läuft jetzt alles.

Danke für die Hilfe.