Ich benötige derzeit leider folgenden komplizierten Aufbau.
Über ein Fortschrittsdialog muss ein Signal an einen Thread geschickt werden, die QThread Klasse wiederum führt selbst eine Klasse aus, an die ich das Signal leider nicht direkt leiten kann.
Also versuche iche so:
SIGNAL Main Thread -> SIGNAL QThread class -> SLOT final class
Signal bzw ein Testslot in der QThread Klasse wird aufgerufen, der eigentliche Slot aber nicht.
Wo habe ich da einen Denkfehler bzw was kann ich machen, um das Problem zu lösen?
Wenn ihr noch mehr Informationen braucht, kann ich die gerne liefern.
Signal zu Thread + Forward
Ich habe es mit:
In konnte es mit einer kontinuierlich aufgerufenen Funktion im Thread lösen.
Alles irgendwie nicht wirklich schön, aber wohl nicht anders machbar.
Wie zeitintensiv ist processEvents. Macht es Sinn dort flags zu setzen oder vorher zu gucken, ob Events vorhanden sind?
Das ausführen von processEvents() direkt nach emit bringt leider gar nichts. Das wäre eine ziemlich gute Lösung gewesen.[/code]
Code: Alles auswählen
QCoreApplication::processEvents();
Alles irgendwie nicht wirklich schön, aber wohl nicht anders machbar.
Wie zeitintensiv ist processEvents. Macht es Sinn dort flags zu setzen oder vorher zu gucken, ob Events vorhanden sind?
Das ausführen von processEvents() direkt nach emit bringt leider gar nichts. Das wäre eine ziemlich gute Lösung gewesen.[/code]
Mir stellt sich zB. die Frage, wo dein Klassenobjekt in deinem Thread ins Leben gerufen wird und somit auch: Wo das Objekt "lebt".
Falls dein eigener Thread die Arbeit übernehmen soll, wenn über ein Signal ein Slot angesprochen wird, muss der schon in seine Event-Loop gehen. Ansonsten wird ja nur deine run() ausgeführt und das war's aus der SIcht des eigenen Threads.
Falls du an das eigene Klassenzielobjekt herankommst, kannst du da auch direkt verbinden. Die wichtige Frage lautet halt: Wo lebt das Objekt --> welcher Thread führt den Funktionscode aus....
Falls dein eigener Thread die Arbeit übernehmen soll, wenn über ein Signal ein Slot angesprochen wird, muss der schon in seine Event-Loop gehen. Ansonsten wird ja nur deine run() ausgeführt und das war's aus der SIcht des eigenen Threads.
Falls du an das eigene Klassenzielobjekt herankommst, kannst du da auch direkt verbinden. Die wichtige Frage lautet halt: Wo lebt das Objekt --> welcher Thread führt den Funktionscode aus....
Mir ist das eh alles ein bisschen suspekt.
Die Klasse wird in run des Threads erzeugt und ich kann sie nicht direkt mit dem GUI-Prozess verbinden, da die Klasse in run in einer Schleife läuft und dort mehrmals erzeugt wird + Signale verbunden werden.
Eine Möglichkeit wäre wahrscheinlich einen Widget-Zeiger mit rüber zu geben, aber das ist mir dann doch ein zu katastrophales Design.
Die Klasse wird in run des Threads erzeugt und ich kann sie nicht direkt mit dem GUI-Prozess verbinden, da die Klasse in run in einer Schleife läuft und dort mehrmals erzeugt wird + Signale verbunden werden.
Eine Möglichkeit wäre wahrscheinlich einen Widget-Zeiger mit rüber zu geben, aber das ist mir dann doch ein zu katastrophales Design.
Ich weis ja nun nicht, was du genau vorhast / kenne deinen Code nicht, aber wenn es darum geht, dass du aus deinem Main-Thread / ProgressBar zu gewissen Zeiten an einen Thread Arbeiten delegierst, sollte dass doch erstmal kein Problem sein.
Dann weis ich nicht, ob zwingend ein eigener Thread benötigt wird.
Falls du sowas vorhast wie: MainTHread startet eigenen Thread und der Thread soll irgendwann bescheid geben, wenn er fertig ist, damit dann deine ProgressBar voranschreitet, sollte man sich Mutex, Semaphore anschauen, bzw. verwenden.
Dann weis ich nicht, ob zwingend ein eigener Thread benötigt wird.
Falls du sowas vorhast wie: MainTHread startet eigenen Thread und der Thread soll irgendwann bescheid geben, wenn er fertig ist, damit dann deine ProgressBar voranschreitet, sollte man sich Mutex, Semaphore anschauen, bzw. verwenden.
Der GUI-Thread erstellt ein Progress Window. Dort wird der Worker-Thread erstellt. Der wiederum ruft in einer Schleife in Run eine Klasse auf, die wiederum die eigentliche Arbeit macht.
Diese endgültige Klasse besteht zum größten Teil als Callback Funktionen für eine DLL. In diesen Funktionen wird der Fortschritt natürlich über die Thread-Klasse zum GUI-Thread gesendet (funktioniert einwandfrei).
Im Fortschrittsdialog muss nun aber die Möglichkeit bestehen Pause und Stop zu drücken, was die Callback-Klasse wissen muss.
Dort besteht jetzt einzig das genannte Problem. Ich konnte das Signal an die Thread-Klasse schicken, aber von dort nicht weiterleiten.
Aber wie oben beschrieben, habe ich das Problem ja lösen können.
Mutex und Semaphore sind doch elementare Teile für die Sicherheit eines Threads, bringen mir aber zur Abwendung des Problems keinen Vorteil.
Diese endgültige Klasse besteht zum größten Teil als Callback Funktionen für eine DLL. In diesen Funktionen wird der Fortschritt natürlich über die Thread-Klasse zum GUI-Thread gesendet (funktioniert einwandfrei).
Im Fortschrittsdialog muss nun aber die Möglichkeit bestehen Pause und Stop zu drücken, was die Callback-Klasse wissen muss.
Dort besteht jetzt einzig das genannte Problem. Ich konnte das Signal an die Thread-Klasse schicken, aber von dort nicht weiterleiten.
Aber wie oben beschrieben, habe ich das Problem ja lösen können.
Mutex und Semaphore sind doch elementare Teile für die Sicherheit eines Threads, bringen mir aber zur Abwendung des Problems keinen Vorteil.