SendMessage PostMessage Struktur
-
Nimm einfach eine std::queue, pack einen Synchronisationsmechanismus drum (zB mit CriticalSection) und sende dem Empfänger einfach nur die Botschaft, dass er was abholen soll. An Stelle der Nachricht kann man auch Events verwenden (die ich ebenfalls sehr zu schätzen gelernt habe).
Ich hab damals, in meiner Verzweiflung einen Ringpuffer gebastelt...
Ich muss mal schauen, wo das Problem genau herkommt. Ob es etwas Compilerspezifisches ist, oder an der Speicherverwaltung der VCL-Klassen im Borland C++ Builder liegt... Werde ich aber in den nächsten Tagen nicht zu kommen.
-
ok danke,
aber wie gehts das mit den events? ich muss ja dann in der GUI nen thread laufen haben, welcher auf ein events wartet, welches ich vom anderen thread aus setze oder?
-
Wie man es mit Events macht hängt davon ab, wie Dein UI Thread funktioniert.
Ich verwende gerne MsgWaitForMultipleObjectsEx...
Aber man kann auch einfach mit WaitForSingleObject(,0) prüfen ob ein Event gesetzt ist,
Wo Du das machst, ob in einem Timer, oder in einem anderen Handler ist sehr abhängig von Deiner Applikation.Es gibt eben kein pauschales: "Man macht es so und so..."
Nur deshalb habe ich mich überhaupt in diese Diskussion eingemischt. Mit war die Antwort von BorisDieKlinge zu pauschal. Ich wollte nur andere Möglichkeiten auch noch genannt haben.
-
Das ist irgendwo warten muss auf ein Event is mir klar.. aber dafür brauch ich ja ein extra thread in der UI welcher auf das event warte und dann gegenfalls die queue lese.. mit nem post message kann ich mir den extra thread der auf ein evetn warte sparen.. das meinte ich
-
BorisDieKlinge schrieb:
sorry wenn dir der begriff Prozess nich gefallen hat. meinte damit trhead bzw. prozess innerhalb eines prozesse also trheads!
Dein Fachwissen hin oder her! jeder hat recht , je nachdem wie man die frage interpretiert..
Sorry, aber das ist Unfug. "jeder hat recht , je nachdem wie man die frage interpretiert.." - was ist das eigentlich für eine sinnfreie Aussage?
Joe_M. schrieb:
BTT:
@CodeFinder: Funktioniert Dein Beispiel ohne Einschränkungen, mit jedem Compiler? Manchmal habe ich das Gefühl, der BCB nimmt es einem übel, wenn man Speicher nicht im gleichen Thread wieder freigibt, in dem man ihn reserviert hat.
Ich hatte ein Projekt, in dem ich das ähnlich gemacht habe, wie in Deinem Beispiel, aber nach ein paar Wochen Laufzeit ist mir das Programm immer weggeschmiert, da kein Speicher mehr reserviert werden konnte... Erst als ich das so umgeschrieben habe, dass der Speicher immer in dem Thread freigegeben wird, in dem er auch reserviert wurde, ist der Fehler verschwunden (da dies aber weitere Umstrukturierungen im Programm notwendig machte, kann ich das nur vermuten).Also: ja^^. Eigentlich gilt der gleiche Adressraum innerhalb eines Prozesses. Hab vllt. irgendwo noch ne BCB-Installer-Datei - könnte das dann mal ausprobieren, aber wenn das Problem eben nur "manchmal" auftritt und dann auch nur "eventuell" aus dem Grund, ist das schwierig nachzuvollziehen
. Aber kann (wie Du schon angedeutet hast) vllt. an ein paar "Eigenheiten" VCL-Klassen bzw. des Compiler sein^^.
BorisDieKlinge schrieb:
Das ist auch vorrausetzung für die tadelose funktionweise... Thread A: resrviert speicher und Thread B bzw. GUI bekommt einen Pointer auf den speicher via PostMessage. Thread B sollte die daten auch NUR lesen..Thread A sollte sich um die zerstörung kümmern..
Nein, das ist *nicht* "vorrausetzung für die tadelose funktionweise"...
-
queue frage schrieb:
Das ist irgendwo warten muss auf ein Event is mir klar.. aber dafür brauch ich ja ein extra thread in der UI welcher auf das event warte und dann gegenfalls die queue lese.. mit nem post message kann ich mir den extra thread der auf ein evetn warte sparen.. das meinte ich
Wieso baruchst Du noch einen extra Thread? Der UI Thread läuft doch, dort gbt es OnIdle Mechaismen und es gibt Timer, und man muss auf einen Event nicht warten! Man kann einfach prüfen ob er gesetzt ist!
-
das ist ja ne super idee.. an die OnIdle funktion hab ich gar nich mehr gedacht;) Man lernt nie aus... bzw. man kommt nocht immer auf die ideen;)
-
Bin grad am Probieren wie das OnIdle in MFC verwende aber:
Die OnIdle funktion wird von CDialog nich unterstützt oder? Hab grad bischen rumprobiert.. aber OnIdle ist kein member von CDialog?
-
Hallo,
OnIdle ist aber Methode der CWinThread-Klasse, und da CWinApp von CWinThread abgeleitet ist, kann man die Methode dort überschreiben.
MfG,
Probe-Nutzer
-
OnIdle ist ein Member von z.B. CWinApp, CDocument, CDocTemplate.
Für Dialog schau Dir bitte WM_ENTERIDLE und WM_KICKIDLE an...