qtforum.de

Bei meinen Projekten: nein (um die Eingangsfrage zu beantworten). Bei den Gründen bin ich nicht besonders fantasievoll: die pros und contras werden seit Jahren im Netz abgewogen und können mit Google auch gefunden werden. Meine Gründe sind so in etwa: 1. In C++ können Exceptions nicht überall einges...

Naja.. genau genommen werden "CustomEvents" gar nie "ausgeführt", sondern nur "bearbeitet" (lesen/schreiben). Der Context spielt von daher gar keine Rolle.. was ich mit der Liste meine ist einfach eine klassische Auftragsliste (in Qt3 vermutlich die "QPtrList"...

Ah.. Mist.. ich bin bisher nicht in den Genuss von Qt3 gekommen :wink: Wobei ich da an deiner Stelle nicht lange fackeln würde.. wenn es Qt3 nicht kann, kannst du ja selbst eine mutex-geschützte QList von Events (von Qt oder auch eine eigene Klasse) als "Auftragsbuffer" verwenden... hth!

Wird denn der Thread selbst zu sich verschoben? Wenn nicht, lebt die Thread-Instanz im MainThread.. und dann wird der Event dem Eventloop des MainThreads zugeschoben...

BTW: warum nicht gleich mit Signals/Slots..? Warum der Umweg über Events?

hth..

funktioniert nicht (wird nie getriggered) Ganz einfach: stelle dir das Signal/Slot-Konzept in Threads vor wie eine "Auftrag" (oder von mir aus einen Brief in den Briefkasten des Threads). Wird der Button "btCancel" bei connect(ui->btCancel, SIGNAL(clicked()), tt, SLOT(stopProces...

Ausgezeichnet... sieht wesentlich besser aus als vorher.
Besten Dank!

Wenn sich deine Klasse ausschliesslich um diese Statische Variabel dreht, würde ich gleich von Anfang an eine Singleton-Klasse nehmen, anstelle normaler Klasseninstanzen. Dann hast du das Problem nicht mehr. Falls diese Klasse jedoch auch noch andere, nicht-statische Members hat und du daher unbedin...

Bin gerade zufälligerweise auf genau dieses Detail in der (Thread)-Doku gestossen: If the signal is emitted in the thread which the receiving object has affinity then the behavior is the same as the Direct Connection Also musst du da unbedingt eine QueuedConnection nehmen.. denn die Thread-Affinität...

aber in meinen Anwendungsfall ist threaded einfach nötig, da ich ansonsten meine Anwendung blockieren würde Naja.. genau das wolltest du ja eingangs ("Der MainThread soll warten").. aber belassen wir es dabei, du wirst schon wissen was du brauchst :wink: Ich hab noch was vergessen: // Eig...

Das ganze ist auch kein Server, sondern ein Client... Und diesen Lagere ich in einen eigenen Thread ab, damit dieser in Ruhe seine TCP- Anfragen erledigen kann sowie auf seine Antworten warten usw... Ja, ich weiss. habe das im [EDIT] berichtig.. Ich wiederhole auch gerne nochmals, dass man QTcpSock...

ganz genau :wink: übrigens: QTcpServer ist bereits multithreaded..eigentlich braucht man bei Bedarf nur noch Threads für die einzelnen TCP-Verbindungen, nicht jedoch für den Server... [EDIT] Moment du scheinst da ja ein Client zu haben.. nicht ein Server. Trotzdem: Für den TCP-Client selbst braucht ...

Warum denn keine Signal/Slot-Connection von der GUI zum Thread? Dann musst du in der GUI nur noch emitten... Hin und wieder nutze ich auch "interne" Signals eines Objektes.. z.B. Thread::Thread(.. { connect(this, SIGNAL(job(...)), this, SLOT(...)), Qt::QueuedConnection); } void Thread::job...

Es gibt natürlich auch "traditionelle" Methoden (ohne Qt) dafür, aber ich empfinde die Qt-Variante mit Signal/Slots wesentlich einfacher..Daher: Warum keine (zwei) Signal/Slot-Connections (eine für den Auftrag, eine für das Resultat)? Falls man die GUI in dieser Zeit blockieren möchte, kan...

Fehlt ein "moveToThread(this) im CTor des QThreads..? Wenn das fehlt, wird der Slot im Kontext des MainThreads ausgeführt.. das muss zwar nicht garantiert zu einem Crash führen, ist aber sicher nicht so wie vom Entwickler erwartet..

Bewirkt mein erster Hinweis (connect zu updateGL()) nichts?