![]() |
Seltsame Eigenheit von TMemo/TFileStream/string
Ich habe folgenden Code geschrieben, der auch problemlos jede Art von Datei einliest. Dabei gibt es bloß ein Problem: Wenn ich, anstatt buffer immer gleich an Memo1.Text anzuhängen, an eine String-Variable anhänge und diese später dem Memo zuweise, ergeben sich bei der Darstellung Unterschiede zur aktuellen Lösung. Kann mir das jemand erklären???
Code:
procedure TForm1.mnuOeffnenClick(Sender: TObject);
var datei: file; buffer: byte; begin if opendialog1.Execute then begin memo1.Clear; assignfile(datei,opendialog1.FileName); reset(datei,1); while not eof(datei) do begin blockread(datei,buffer,1); if buffer = 0 then buffer := 32; memo1.Text := memo1.Text + chr(buffer); end; closefile(datei); end; end; |
Hoi,
warum denn so umständlich ???
Delphi-Quellcode:
memo1.Lines.LoadFromFile(opendialog1.FileName);
|
Moin BrainCode,
mal abgesehen davon, dass Roman's Methode wohl sinnvoller ist: Worin besteht denn der Unterschied, wenn Du statt Memo1.Text immer zu erweitern eine String Variable immer erweiterst, und diese dann Memo1.Text zuweist. BTW: Immmer einzelne Byte einzulesen und einem String zuzuweisen, ganz speziell Memo.Text, drückt ganz erheblich auf die Performance. |
Moin Christian,
Zitat:
Habe es letzte Woche in der Arbeit erst wieder gemerkt. Eine Software schreibt Daten auf die Serielle(mit nur 19kBaud), dabei wird in einer Memo angezeigt, was alles geschrieben worden ist. Das funktionierte unter NT ganz gut, nur auf ME überhaupt nicht. Die Datenübertragung hat überhaupt nicht geklappt, da Windows total überfordert war, gleichzetig was in der Memo zu schreiben. Ja ja, ME ist auch ein Multi-Threading System, dennoch bringt es nichts auf die Reihe. Das ist der kleine aber feine Unterschied zwischen 9xME und NT2k. Da liegen eindeutig Welten dazwischen. Achja, ProcessMessages bringt da auch nichts mehr. Grüsse, Daniel :hi: |
Von der Theorie her ist mir klar, dass LoadFromFile einfacher ist und das es keinen Unterschied macht, ob ich direkt in das Memo schreibe oder ob ich erst per String puffere.
Zu LoadFromFile: Diese Funktion hört bei Binärdateien nach dem ersten Null-Zeichen ( chr(0) ) auf zu lesen. Ich habe die Frage eigentlich nur gepostet, weil ich wissen wollte, WARUM es ein Unterschied ist, ob ich das Ganze in einem String puffere. Ich habe keine Ahnung warum, aber es ergibt sich ein Darstellungsunterschied. Probiert den Code doch bitte mal bei euch mit einer EXE aus, bei mir hat es mit der ftp.exe aus dem Windows-Verzeichnis ganz gut geklappt. Ich benutze Win98 SE. Versucht dann mal, anstatt in Memo in einen zweiten Puffer zu schreiben (string) und diesen im Memo ausgeben zu lassen, nachdem der Lesevorgang beendet ist. |
Mir ist noch etwas eingefallen:
Das Schreiben in ein Memo wird bei mir wesentlich schneller, wenn ich die Scroll-Animationen von Windows ausschalte. Die meißte Zeit wird also von der Animation geschluckt. |
Zitat:
Das kann man ganz leicht ausprobieren, indem man eine Konsolenanwendung schreit, die einfach bis 1 Million hochzählt und dabei die aktuelle Zalh immer in eine neue Zeile schreibt. Das dauert schon etwas. Wenn man dagegen die Ausgabe in eine Datei umleitet, dauert der Vorgang gerade einmal ein paar Sekunden. |
Moin BrainCode,
Zitat:
Was Du allerdings immer noch nicht erzählt hast: Wo ist denn nun der Darstellungsunterschied? |
Ich will auch Binärdaten ansehen können, weil ich Notepad nachprogrammieren und um einige Funktionen erweitern will. Der Code für's Einlesen ist jetzt auch erledigt.
Der Darstellungsunterschied ergab sich daraus, das auch bei Strings das Zeichen 0 als Ende-Zeichen interpretiert wird. Um es Notepad nachzumachen ersetze ich aber alle 0-Zeichen durch 31-Zeichen (Space), wodurch das Problem beseitigt wird. Nur Speichern kann man die Binaries dadurch nicht, aber das Problem hat ja Notepad auch, dafür gibt's ja Hex-Editoren. |
Moin Braincode,
falls es von Dir kein Schreibfehler war: Space ist #32. Das ist der Wert den Notepad auch für die #00 einsetzt, und Speichern kann man dann auch. Hat nur den kleinen Nachteil, dass die Datei danach zerstört ist, da ja alle #00 durch #32 ersetzt wurden. Um das zu umgehen müsste man sich alle Positionen von #00 in der Datei merken und beim Speichern wieder zurücksetzen. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 07:51 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz