|
Anzeige
|
Klasse für gui in qt/ c++
Gast
#4844157
Hallo, ich habe eine Frage zu C++/Qt. Ich erstelle mir gerade eine Gui mit Qt und C++ in VisualStudio. Verstehe ich das richtig, dass die Gui das einzige Objekt dieses Projektes ist und es somit nur eine Klasse gibt? Also alle Elemente die ich in die Gui packe, kommen ja in diese Klasse. Was wäre ein Beispiel, wo man mehrere Klassen für die Gui hat? Lars Hallo Lars, man kann alles in eine Klasse packen. Ist aber nicht sinnvoll. Besser ist eine Trennung in einzelne Zuständigkeiten. Mehrere Klassen in GUI bekommst Du auf jeden Fall, sobald Du noch andere Dialoge benötigst. BTW: wieso nicht QT Creator statt VS? mfg Olaf Lars schrieb: > Hallo, > ich habe eine Frage zu C++/Qt. > Ich erstelle mir gerade eine Gui mit Qt und C++ in VisualStudio. > Verstehe ich das richtig, dass die Gui das einzige Objekt dieses > Projektes ist und es somit nur eine Klasse gibt? Nein. In der Regel hat man viele Klassen für die GUI. Mit "die Gui" scheinst du das Hauptfenster zu meinen. Das fasst aber in der Regel nur noch die Funktionalitäten zusammen, die in den anderen Klassen definiert ist.
Gast
#4844190
Rolf M. schrieb: > Mit "die Gui" > scheinst du das Hauptfenster zu meinen Ja genau. Rolf M. schrieb: > Das fasst aber in der Regel nur > noch die Funktionalitäten zusammen, die in den anderen Klassen definiert > ist. Ahso, dann fange ich das auch an sofort zu überarbeiten. Wie würde man die Klassen am besten zusammenfassen? Ich habe z.B. mehrere Tabs in meinem Hauptfenster und dort verschiedene Elemente drinn. Würde man dann jeden Tab in eine eigene Klase zusammenfassen oder z.B. jeden Button (aus allen Tabs) in eine eigene Klasse und andere Elemente (aus allen Tabs) ebenfalls in eine eigene Klasse? Olaf B. schrieb: > man kann alles in eine Klasse packen. Ist aber nicht sinnvoll. Das wird nämlich ein bisschen unübersichtlich. Daher kam mir die Frage auf. Olaf B. schrieb: > BTW: wieso nicht QT Creator statt VS? Keine Ahnung, wurde mir so gezeigt. Ist das Erste Projekt mit Qt Lars Lars schrieb: > Ich habe z.B. mehrere Tabs in meinem Hauptfenster und dort verschiedene > Elemente drinn. Würde man dann jeden Tab in eine eigene Klase > zusammenfassen oder z.B. jeden Button (aus allen Tabs) in eine eigene > Klasse und andere Elemente (aus allen Tabs) ebenfalls in eine eigene > Klasse? Nein. Die Steuerelemente/das Layout innerhalb deines Hauptfensters/GUI bleiben in dieser Klasse. Die Events, die bei Qt Aktionen auslösen ( Signal/Slot-Konzept ) - z.B. starte Motor ( Klasse Motor, Methode start(void) )- werden als eigene Klasse implementiert. mfg Olaf
Gast
#4844419
Olaf B. schrieb: > Lars schrieb: eiben in dieser Klasse. > > Die Events, die bei Qt Aktionen auslösen ( Signal/Slot-Konzept ) - z.B. > starte Motor ( Klasse Motor, Methode start(void) )- werden als eigene > Klasse implementiert. > > mfg > > Olaf Da bringst du aber etwas durcheinander. Signal/Slot-Konzept ist an sich völlig unabhängig von Events. Klar, man kann bei bestimmten Events bestimmte Signale senden. Man kann das aber völlig ohne Events tun. Auch sind Event Handler KEINE SLots. S QWidget zB. Man implementiert eigene Events nur wenn es tatsächlich nötig ist. Innerhalb einer GUI ist das nur in seltensten Fällen notwendig. Hallo dulnik, dann lies bitte das: http://doc.qt.io/qt-5/signalsandslots.html > For example, if a user clicks a Close button, we probably want the window's close() function to be called. mfg Olaf Olaf B. schrieb: > Hallo dulnik, > > dann lies bitte das: http://doc.qt.io/qt-5/signalsandslots.html Und du lies das: http://doc.qt.io/qt-5/eventsandfilters.html >> For example, if a user clicks a Close button, we probably want the >> window's close() function to be called. Das hat aber nur indirekt mit Events zu tun, da der Button auf Maus-Events horcht und darüber erkennt, dass er angeklickt wurde. Aber das war's dann auch. Signale/Slots muss man sich eher wie Callback-Funktionen vorstellen. Und genau wie dulnik geschrieben hat, ist die close()-Funktion in dem Beispiel kein Event-Handler.
Gast
#4845842
Olaf B. schrieb: > Hallo dulnik, > > dann lies bitte das: http://doc.qt.io/qt-5/signalsandslots.html > >> For example, if a user clicks a Close button, we probably want the window's > close() function to be called. > > mfg > > Olaf Dafür brauche ich weder einen neuen Event noch sonst etwas zu implemetieren. Es reicht das clicked() SIGNAL des Buttons mit dem close() SLOT des Fensters mit connect zu verbinden. Wenn ich will, das beim Schliessen des Fensters etwas besonderes passiert dann reimplementiere ich die virtuelle Methode closeEvent() der Fenster-Klasse. Definition einer eigenen Event Klasse, wie du behauptest, ist überhaupt nicht notwendig in solchen Fällen.
Gast
#4845851
Rolf M. schrieb: > Signale/Slots muss man sich eher wie Callback-Funktionen vorstellen. Ja, aber das gilt nur innerhalb des gleichen Threads. Wenn sich SIGNAL und SLOT in verschiedenen Threads befinden, dann wird der SIGNAL/SLOT Mechanismus über den Event Loop implementiert. http://doc.qt.io/qt-4.8/threads-qobject.html#signals-and-slots-across-threads dulnik schrieb: > Rolf M. schrieb: > >> Signale/Slots muss man sich eher wie Callback-Funktionen vorstellen. > > Ja, aber das gilt nur innerhalb des gleichen Threads. Wenn sich SIGNAL > und SLOT in verschiedenen Threads befinden, dann wird der SIGNAL/SLOT > Mechanismus über den Event Loop implementiert. Ja, bzw. allgemein bei "queued connection". Bei mehreren Threads kann die Funktion aus dem einen Thread heraus ja gar nicht im anderen Thread aufgerufen werden. Nachteil bei queued connection ist aber, dass alle Parameter über QDataStream serialisierbar sein müssen und das das alles umständlich über die Eventloop abgewickelt wird. Bei der direct connection ist es nur ein einfacher Aufruf einer Memberfunktion über einen Pointer. Ich hab bisher nur direct connection benutzt, nutze aber Qt auch schon seit einer Zeit, in der es noch nichts anderes gab. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
