Problem mit RichEdit StreamCallback
-
Mir ist Dein Code zu kompliziert. Für was benötigst Du die Datei, wenn Du nur die Daten kopieren willst?
Wir kommst Du darauf, dass Du den Puffer, den Die die Callback Funktion gibt, löschen zu dürfen?
-
Die Datei hFile benötige ich um mit dieser Funktion werte in Dateien (C:\test.txt) zu schreiben oder aus ihr zu lesen.
das gegenstück zu Get- & SetTextStream ist Get- &SetFileStreamWir kommst Du darauf, dass Du den Puffer, den Die die Callback Funktion gibt, löschen zu dürfen
welchen puffer meinst du?
-
Zeile 117
memset(lpBuff,0,cb);
-
weil in dem puffer, alte werte stehen bleiben, wenn die vorhergehende Zeichenfolge länge war, als die aktuelle. deshalb kam ich auf die Idee den zu löschen. ansonsten gibt es keinen Grund dafür.
steht ja auch im Kommentar darüber.
-
Und was interessiert dich das bitte?
Der Callback sagt Dir genau wie weit Du den Speicher zu benutzen hast. Du hast da gar nichts selbst zu ermitteln.
-
LowFly so wie du dir vorgestellst hast, der Code aus deinem ersten Post einfach in Thread packen und ausfuhren, so wird nicht funz.
Du versuchst aus dem Thread auf RichEdit Steuerelement mit Funktion "StreamOut" zugreifen(Threadübergreifend), dein richtige Lösung ist "Threadübergreifende programmierung",schau im netz ob wad findest, ansonsten kann ich dir paar links zu Dokus & Beispiele posten. Kannst dir sicher sein, dass du in deinem Projekt/Code wirst einiges ändern müssen.
-
@MR C
Ah ok,
ja dann poste doch mal die links bitte
-
Mal Grundsätzlich: Du hast also einen anderen Thread der auf das RTF Control zugreift?
Wenn dem so ist, kannst Du den gleich wieder vergessen, weil jede Interaktion letzten Endes durch die Messagequeue synchronisiert wird.Zudem besteht ja sogar die Möglichkeit, dass sich das Control in der Größe bereits verändert hat und entsprechend der Buffer gar nicht passt.
Weiterhin ist nach wie vor, Dein Code ein Witz.
Wir kommst Darauf über strlen auf die Größe eines allokierten Buffers zu schließen? Wenn also im letzten Zyklus nur noch ein Byte übertragen wurde wir dim nächsten Durchgang alles byteweise durchlaufen obwohl der Buffer ursprünglich mal größer war.Dein ganzer Konstrukt mit dem Buffer der irgendwie erhalten bleibt und wieder verwendet wird hat viel zu viele Seiteneffekte.
Ich sehe auch keinen Schutz, dass dieser Buffer nicht aus zwei Threads verwendet werden könnte.Ich habe das mal durchgespielt und bekomme Deine Probleme nicht.
Allerdings kollekiert mein Program einfach alle Daten in einem Puffer.Ich würde davon ausgehen, dass Du einfach einen Fehler in Deinem Code hast.
-
LowFly schau hier rein...
Einführung in Threads:
https://msdn.microsoft.com/de-de/library/ms171728(v=vs.110).aspx?cs-save-lang=1&cs-lang=cpp#code-snippet-1
https://www.labri.fr/perso/betrema/winnt/frogfly1.html
(+SourceCode):
http://www.ucancode.net/Visual_C_MFC_Samples/WaitForSingleObject-_beginthreadex-SetEvent-Start-Stop-Thread-VC-MFC-Example.htm
http://flylib.com/books/en/4.348.1.78/1/
http://www.tenouk.com/visualcplusmfc/visualcplusmfc22.html
https://www.tutorialcup.com/cplusplus/multithreading.htmBeispiele:
http://www.codeproject.com/Articles/14746/Multithreading-Tutorial
http://www.codeproject.com/Articles/43994/The-Practical-Guide-to-Multithreading-Part
http://www.cppfun.com/win32-multi-threads-programming.htm
-
Martin er kann fehler suchen solange es geht. Er hat doch geschrieben, dass der Code ohne Thread funz tadenlos. Ohne "Threadübergreifende programmierung" kommt er kein Schritt weiter. Er greift nicht mit Thread auf RichEdit, sondern aus dem Thread auf RichEdit und so einfach geht das nicht, in NET mus er mit Ivnoke arbeiten.
-
Mit einem Thread ist das doch sowieso quatsch. Er verwendet SendMessage. Also gibt es eine Threadsynchronisation. Da muss man in der Windows API gar nichts machen. Aber ein Thread bringt hier auch keinerlei Vorteile.
-
...fur die hintergrund events ohne die GUI Threads oder andere events zu blockieren wie z.b Emails in Dateien archivieren oder Email versenden und empafngen,usw.... bringen Threads seine voteile.
-
Klar bringen Threads was, aber nur dann wenn sie hinreichend von der UI entkoppelt werden.
Und hier nicht, wenn er SendMessage verwendet und ausgerechnet, dass für eine Operation die länger dauern kann.
-
Martin des habe ich schon erwähnt...wiederhole nicht, dass was ich schon geschrieben habe.