Bei Problem 2 hast du nun zwar die race-cond. geschuetzt, jedoch noch nicht den restlichen Teil.. fast alle Qt-Methoden sind zwar "reentrant" (gleiche Methode kann aus zwei Threads auf zwei unterschiedliche (!) Instanzen angewendet werden) aber nicht multithreading-tauglich (Methode einer bestimmten Instanz (bei dir "deb"-Pointer) von zwei Threads gleichzeitig aufrufen)... du musst also die gesamte Methode mittels Mutex schuetzen.
Zu Problem 1: das kannst du so nicht loesen. Du darfst vom Thread her keine Methoden deiner "deb"-Instanz her aufrufen. Auch die QMessageBox benoetigt das Display und gehoert nicht zum Worker-Thread. Vom Prinzip her sollte das (wie du schon mit Signals probiert hast) so sein, dass der Thread irgendwie (Shared-Bereich, IPC, Signals...) die Info an die GUI weitergibt und die Anzeige erst da erfolgt.
QConcurrent oder QThread? Wie multithreaden in Qt 4.4.0?
hmm wo kan nich infos zum Thema shared nachlesen? wie mache ich etwas shared?
ich denke das es reicht wenn ich den direkten aufruf des appends
gegen Signal&Slots auswechseln.
Ich habe es soweit das der Handler erkennt wenn fremde Threads posten wollen - so dass er es vorerst nur beim eigenen macht. Es bleibt also ncoh das Problem was ihc machen muss WENN ich erkenne das es ein andere Thread ist. Leider lassne sich QStrings nicht mit "MoveToOtherThread" verschieben.
Kann ihc signals emitten ohnen sie vorher zu definieren? Habe ja kein
Q_OBJECT - Macro da ich keine Klasse als debughandler habe.
arg das ist zu mVerzweifeln, ich kann doch ned der erste sein der simple qDebug()-Funktionen in workerthreads nutzen will!!! wie machten das den "richtige Programmierer" ?
kann doch ned sein das ich soviel Zeit in so einen Kleinscheiß investieren muss bis ich wieder eine Debugmöglichkeit habe?!?!
Viele grüße vom verzeifelten Torben *schwarzer Rauch aus dne Ohren komm*
ich denke das es reicht wenn ich den direkten aufruf des appends
Code: Alles auswählen
deb->append(QString("<b>Debug:</b> ")+QString(msg));
Ich habe es soweit das der Handler erkennt wenn fremde Threads posten wollen - so dass er es vorerst nur beim eigenen macht. Es bleibt also ncoh das Problem was ihc machen muss WENN ich erkenne das es ein andere Thread ist. Leider lassne sich QStrings nicht mit "MoveToOtherThread" verschieben.
Kann ihc signals emitten ohnen sie vorher zu definieren? Habe ja kein
Q_OBJECT - Macro da ich keine Klasse als debughandler habe.
arg das ist zu mVerzweifeln, ich kann doch ned der erste sein der simple qDebug()-Funktionen in workerthreads nutzen will!!! wie machten das den "richtige Programmierer" ?
kann doch ned sein das ich soviel Zeit in so einen Kleinscheiß investieren muss bis ich wieder eine Debugmöglichkeit habe?!?!
Viele grüße vom verzeifelten Torben *schwarzer Rauch aus dne Ohren komm*
Vielleicht erklärst du uns nochmals das Problem... denn RHBaum hat doch eigentlich alles schon gesagt..?kann doch ned sein das ich soviel Zeit in so einen Kleinscheiß investieren muss bis ich wieder eine Debugmöglichkeit habe?!?!
Also entweder benutzt du überall einfach qDebug() und hast alle Ausgaben in der Konsole (was genau spricht denn da dagegen?). Oder du möchtest die Meldungen in der GUI anzeigen. In diesem Fall verzichtest du am besten auf qDebug() und implementiert eine saubere Lösung (Threads übermitteln Mitteilungen an den Hauptthread). Diese Lösung könnte aus einem simplen Signal bestehen, oder einer etwas angepassteren Lösung (z.B. ein gemeinsamer (shared) Daten-Puffer, welcher von den Threads gefüllt und von der GUI angezeigt wird).
Sei ned boese, aber irgendwie versuchst du grad mit nem Hammer auf was einzukloppen, was du ned verstehst 
Arbeite Dich noch mal in das Thema, Code, Daten ... usw ein, besonders bissi verstaendniss zu dem was der prozessor genauer macht, sollte auch in richtung multithreading bissi mehr klarheit und verstaendiss bringen. Besonders das nen Object
nstanz) nicht lebt, also nix allein machen kann. Auf Dauer wirst da ohne Grundlagen in der Richtung ned gluecklich werden.
Auch wenn man QThread benutzt, sollte man sich mit so lowlevel Dingen auskennen, grad beim multithreading. Es gibt viel zu viele Stolpersteine da !
Ciao ...
Ich weiss ned welcher OOP Fanatiker da Experimente an deinem Gehirn gemacht hat, aber da gehoert definitiv was richtig gestelltIch erstelle aber das Debug-Textedit nicht im Workerthread sondern anfans im GUIThread! Danach exisitert es ja und wird nicht neu erstellt.
Arbeite Dich noch mal in das Thema, Code, Daten ... usw ein, besonders bissi verstaendniss zu dem was der prozessor genauer macht, sollte auch in richtung multithreading bissi mehr klarheit und verstaendiss bringen. Besonders das nen Object
nstanz) nicht lebt, also nix allein machen kann. Auf Dauer wirst da ohne Grundlagen in der Richtung ned gluecklich werden. Auch wenn man QThread benutzt, sollte man sich mit so lowlevel Dingen auskennen, grad beim multithreading. Es gibt viel zu viele Stolpersteine da !
Ciao ...
OK, nohcmla zusammegefasst:
Das Problem ist: In Windows gibt es im Gegensatz zu Linux keine Fehlerkonsole. Wenn ich also Debugmeldungen habe, sehe ich sie unter Windows einfach nicht, sofern ich eine grafische Anwendung programmiere.
->ich muss mir ein Mechanismus bauen, der mir auch unter Windows in einer GUI-Anwendung meine Debug-Messages ausgibt.
-> ich habe in meinem Single-Threading Programm also eine QTextEdit, in das die Debugmeldungen immer geschrieben werden ( append(...) ) - was auch prima funktioniert.
nun zum Multithreaden:
Wenn ich nun in meinem Workerthread eine Debug-Meldung absende, dann geht der Workerthread in dne Debughandlerm erkennt es dort als Debugmessage ( oder Warning ider Critical, was es halt ist) und schreibt es in der entsprechendne Farbe in das Textedit mittels append.
genau an diesem textedit->append(msg); scheitert er, weil er dann eine Assert absetzt, ich könne nur von GUI-Thread auf dieses Widget schreiben.
Frage:
Wie kann ich denn dafür Sorgen dass die eigentliche Schreiben der Meldung nicht mehr im Worker sondern im GUI-Thread stattfindet?!
Es muss doch für windowsler eine Möglichkeit geben, ihre Debugmeldungen auch von Workerthreads sehen zu können?!?
Das Problem ist: In Windows gibt es im Gegensatz zu Linux keine Fehlerkonsole. Wenn ich also Debugmeldungen habe, sehe ich sie unter Windows einfach nicht, sofern ich eine grafische Anwendung programmiere.
->ich muss mir ein Mechanismus bauen, der mir auch unter Windows in einer GUI-Anwendung meine Debug-Messages ausgibt.
-> ich habe in meinem Single-Threading Programm also eine QTextEdit, in das die Debugmeldungen immer geschrieben werden ( append(...) ) - was auch prima funktioniert.
nun zum Multithreaden:
Wenn ich nun in meinem Workerthread eine Debug-Meldung absende, dann geht der Workerthread in dne Debughandlerm erkennt es dort als Debugmessage ( oder Warning ider Critical, was es halt ist) und schreibt es in der entsprechendne Farbe in das Textedit mittels append.
genau an diesem textedit->append(msg); scheitert er, weil er dann eine Assert absetzt, ich könne nur von GUI-Thread auf dieses Widget schreiben.
Frage:
Wie kann ich denn dafür Sorgen dass die eigentliche Schreiben der Meldung nicht mehr im Worker sondern im GUI-Thread stattfindet?!
Es muss doch für windowsler eine Möglichkeit geben, ihre Debugmeldungen auch von Workerthreads sehen zu können?!?
Jein, du hasst genau wie in Linux nen stdin,stderr, stdout ....Das Problem ist: In Windows gibt es im Gegensatz zu Linux keine Fehlerkonsole. Wenn ich also Debugmeldungen habe, sehe ich sie unter Windows einfach nicht, sofern ich eine grafische Anwendung programmiere.
ne win32 anwendung oeffnet aber standardmaessig keine konsole, trotzdem ist der output buffer da ....
wuerdest du das ding aus ner konsole raus starten, wuerdest du den output sehen. Macht unter windows aber keiner ....
du kannst ueberigens auch win32 anwendungen so compileieren, dass sie ne console alleine aufmachen, und trotzdem win32Gui elemente anzeigen.
Aber das mit der Farbe wuerde dir dann abgehen ...
Entkoppeln ....Wie kann ich denn dafür Sorgen dass die eigentliche Schreiben der Meldung nicht mehr im Worker sondern im GUI-Thread stattfindet?!
vom workerthread in den GUI thread switchen, ist unter QT4! eines der leichteren uebungen .... siehe signal Slot mechanismuss. der nimmt dir das ganze mit eventerzeugung etc ab ... Einfach ueber nen signal Slot schicken, und voiala, du bist im gui thread !
Ciao ....