Autor |
Beitrag |
Melanie
      
Beiträge: 33
|
Verfasst: So 20.10.02 09:20
Hallo,wie löscht man in einem Richedit nach einem Leerstring alle nachfolgenden Zeilen bis zum Ende der Datei?
Folgender Quelltext funktioniert auch nicht(m ist als integer var deklariert)
Quelltext 1: 2: 3: 4: 5: 6: 7: 8:
| s:=' '; for i:= 0 to richedit1.Lines.Count -1 do begin m:=richedit1.Lines.IndexOf(s); for m:= m to richedit1.Lines.Count -1 do begin application.ProcessMessages; richedit1.Lines.Delete(m); end; end; |
MfG Melly 
|
|
Christian S.
      
Beiträge: 20451
Erhaltene Danke: 2264
Win 10
C# (VS 2019)
|
Verfasst: So 20.10.02 11:48
Hi!
So geht's, glaube ich:
Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12:
| procedure TForm1.Button1Click(Sender: TObject); VAR leerpos : Integer; temp : STRING; begin leerpos:=Pos(' ',RichEdit1.Text); if leerpos > 0 THEN begin temp:=RichEdit1.Text; Delete(Temp,leerpos+1,Length(temp)-leerpos+1); RichEdit1.text:=temp; END; end; |
Oder wenn es um eine LEERZEILE geht:
Quelltext 1: 2: 3: 4: 5: 6: 7: 8:
| procedure TForm1.Button1Click(Sender: TObject); VAR leerpos,i : Integer; begin for leerpos:=0 TO RichEdit1.Lines.Count-1 DO IF RichEdit1.Lines[leerpos]='' THEN break; FOR i:=RichEdit1.Lines.Count-1 DOWNTO leerpos+1 DO RichEdit1.Lines.Delete(i); end; |
MfG,
Peter
_________________ Zwei Worte werden Dir im Leben viele Türen öffnen - "ziehen" und "drücken".
|
|
Melanie 
      
Beiträge: 33
|
Verfasst: So 20.10.02 12:31
Titel: Strings
Hallo Peter,danke für Deinen Quelltext,aber der funktioniert leider nicht bei
mir.Im ersten Fall bleibt nur die Zahl '10' von 40 MB eingelesenem Text
übrig.Beim nächsten friert das Programm ein.
MfG Melly 
|
|
Christian S.
      
Beiträge: 20451
Erhaltene Danke: 2264
Win 10
C# (VS 2019)
|
Verfasst: So 20.10.02 13:10
Hi!
Hast Du mal versucht, mit ein paar MessageBoxen herauszufinden, wo er sich beim zweiten Quelltext aufhängt? Es könnte bei 40MB Text ja doch eine ganze Weile dauern! Wenn ich das ganze mal mit zwanzig Zeilen oder so ausprobiere, dann funktioniert der Quelltext.
MfG,
Peter
_________________ Zwei Worte werden Dir im Leben viele Türen öffnen - "ziehen" und "drücken".
|
|
Melanie 
      
Beiträge: 33
|
Verfasst: So 20.10.02 19:16
Titel: Strings
Hallo Peter , gibt es eine Möglichkeit eine Datei schon beim Einlesen in ein Richedit zu veranlassen, daß sie nur bis zum ersten Leerstring eingelesen wird .
Dann könnte ich mir das nachträgliche Löschen ja sparen und die Datei währe wesentlich kleiner.
MfG Melly 
|
|
Wolff68
      
Beiträge: 302
Erhaltene Danke: 1
WinXP home
D6 Prof
|
Verfasst: So 20.10.02 19:38
Also bei so einer Menge Text würde ich vielleicht versuchen das ohne durchlaufen der Zeilen zu erreichen.
Eine Zeile hört ja immer mit #$D#$A auf, wenn also 2 Zeilenvorschübe hintereinander stehen ist die Leerzeile gefunden.
Quelltext 1: 2: 3:
| Ende := Pos(#$D#$A#$D#$A,Memo1.Text); IF Ende > 0 then Memo1.Text := Copy(Memo1.Text,0,Ende-1); |
Ich hab nur keine Ahnung ob Pos() bei einer so großen Datei nicht überläuft, weil das Ergebnis laut Hilfe 'nur' ein Integer ist.
_________________ "Der Mensch ist nicht was er sich vorstellt oder wünscht zu sein, sondern das was andere in ihm sehen."
|
|
Wolff68
      
Beiträge: 302
Erhaltene Danke: 1
WinXP home
D6 Prof
|
Verfasst: So 20.10.02 19:52
Hey, auch 'ne gute Idee. Du musst nur eben die Zeilen einzeln einlesen und überprüfen.
Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14:
| procedure TForm1.Button2Click(Sender: TObject); var F : TextFile; S : String; begin Memo1.Lines.Clear;
AssignFile(F,'F:\ReadLnTest.txt'); Reset(F); Repeat ReadLn(F,S); Memo1.Lines.Add(S); until (S = '') OR EOF(F); CloseFile(F); end; |
In diesem Fall hast eben am Schluß noch die Leerzeile mit drinstehen.
Müsste man die Schleife ein bischen umstellen...
_________________ "Der Mensch ist nicht was er sich vorstellt oder wünscht zu sein, sondern das was andere in ihm sehen."
|
|
Christian S.
      
Beiträge: 20451
Erhaltene Danke: 2264
Win 10
C# (VS 2019)
|
Verfasst: So 20.10.02 20:09
Stimmt, das ist die beste Idee. Evtl. sollte man noch ein BeginUpdate und EndUpdate einfügen.
MfG,
Peter
_________________ Zwei Worte werden Dir im Leben viele Türen öffnen - "ziehen" und "drücken".
|
|
Wolff68
      
Beiträge: 302
Erhaltene Danke: 1
WinXP home
D6 Prof
|
Verfasst: So 20.10.02 20:19
Hast recht Peter.
Nicht nur vielleicht. Bei so großen Dateien empfielt sich das auf jeden Fall. Sonst flackert das nur unnötig in der Gegend rum und verbraucht Rechenzeit. Hab ich eben nicht dran gedacht.
Eventuell könnte man hier auch noch über eine ProgressBar anzeigen, daß die Datei am laden ist. Dann weis der User Bescheid, daß seine Kiste was arbeitet 
_________________ "Der Mensch ist nicht was er sich vorstellt oder wünscht zu sein, sondern das was andere in ihm sehen."
|
|
Christian S.
      
Beiträge: 20451
Erhaltene Danke: 2264
Win 10
C# (VS 2019)
|
Verfasst: So 20.10.02 20:59
Für den Progressbar müsste man aber wissen, wieviel Zeilen man hinzufügt. Aber das weiß man erst am Ende, wenn das ganze schon erledigt ist. Man könnte aber eine dieser Standardanimationen laufen lassen. "FindFile" würde, glaube ich, am besten passen.
_________________ Zwei Worte werden Dir im Leben viele Türen öffnen - "ziehen" und "drücken".
|
|
Wolff68
      
Beiträge: 302
Erhaltene Danke: 1
WinXP home
D6 Prof
|
Verfasst: So 20.10.02 21:09
Oder man nimmt bei Textfiles die Filesize.
Und dann den Progress auf Progress+Length(Zeile) setzen...
Weis aber grad auch nicht, ob man damit das MAX genau erreicht. Aber da ist ProgressBar glaub nicht so heikel, oder man fängt es ab.
Müsste man mal ausprobieren. Bei großen Dateien kann ein eventueller Versatz schon recht groß werden, und ausserdem haben wir dann wieder das Problem daß eventuell ein Integer überläuft...
War eben so 'ne Idee.
_________________ "Der Mensch ist nicht was er sich vorstellt oder wünscht zu sein, sondern das was andere in ihm sehen."
|
|
Christian S.
      
Beiträge: 20451
Erhaltene Danke: 2264
Win 10
C# (VS 2019)
|
Verfasst: So 20.10.02 21:39
Das mit dem Versatz war das, was ich meinte. An den Integer hatte ich gar nicht gedacht, aber das könnte auch zum Problem werden. Das könnte man ja aber noch lösen, indem man das progressbar.max nicht auf FileSize setzt, sondern auf 100 und dann guckt, alle wieviel Bytes man um eins erhöhen muss (also Bytes / Prozent).
MfG,
Peter
P.S.: Das mit dem Versatz stört viele andere Programmierer auch nicht. Meistens ist der örtliche Wahrsager genauer als ein Progressbar. Habe sogar schon mal gesehen, wie einer wieder ein Stück rückwärts lief! 
_________________ Zwei Worte werden Dir im Leben viele Türen öffnen - "ziehen" und "drücken".
|
|
Wolff68
      
Beiträge: 302
Erhaltene Danke: 1
WinXP home
D6 Prof
|
Verfasst: So 20.10.02 23:30
Also Rückwärts ist krass
Aber das mit der Filesize haut bei TextFiles eh nicht hin. Da müsste man schon mit FindFirst usw. arbeiten. Habs mal ausprobiert und kommt nicht schlecht hin. In der FMXUTILS.PAS ist so eine Funktion drin zum nachschauen...
ABER WIR HABEN EIN GANZ ANDERES PROBLEM:
Ich hab das jetzt mal mit einem RichEdit und einer RTF-Datei ausprobiert. Wenn ich da die Lines mit ReadLn einlese zeigt er mir das im PlainText an und nimmer Formatiert !!!
Hast Du vielleicht eine Ahnung warum!?
_________________ "Der Mensch ist nicht was er sich vorstellt oder wünscht zu sein, sondern das was andere in ihm sehen."
|
|
Luckie
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: Mo 21.10.02 01:58
Ist auch klar warum oder?
ReadLn liest eien Textdatei zeilenweise ein und ReadLn sind die RTF-Tags schnurz piep egal.
|
|
MathiasSimmack
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: Mo 21.10.02 08:23
Lösung -
Den Aufbau einer RTF-Datei ansehen und schauen, wie z.B. eine Leerzeile aussieht. Imho ist das eine Zeile, die nur dies enthält:
Quelltext
Das heißt, zeilenweise mit "ReadLn" einlesen könnt ihr sie trotzdem. Wenn euch aber die erste Leerzeile interessiert, dann müsst ihr gucken, ob der obige RTF-Code mit dem gelesenen String übereinstimmt.
Wenn ihr das Lesen dann vorzeitig unterbrecht, dann solltet ihr auch wieder bedenken, dass RTF kein simples (Plain-)Textformat ist. Es gibt also ein (ich sag´ mal:) standardisiertes Ende.
|
|
Christian S.
      
Beiträge: 20451
Erhaltene Danke: 2264
Win 10
C# (VS 2019)
|
Verfasst: Mo 21.10.02 15:56
Hi!
Ich habe mal versucht, den Vorschlag von Mathias umzusetzen, aber dieser Code funktioniert nicht. Wahrscheinlich ein Fehler, bei dem ich im nächsten Posting ein "Ups"-Smily setzen muss, aber ich finde ihn einfach nicht.
Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16:
| VAR datei : TextFile; s : STRING; begin AssignFile(datei,'c:\test.rtf'); Reset(datei); Readln(datei,s);
RichEdit1.Clear; while not ((s='\par') or EOF(datei)) do begin RichEdit1.Lines.Add(s); Readln(datei,s); end; if s='\par' then RichEdit1.Lines.Add('\par }'); CloseFile(datei); end; |
Der Fehler tritt auf, wenn ich die allererste Zeile hinzufügen will. "RichEdit line insertion error". Sagt mir eigentlich nichts. Wo ist der Fehler?
MfG,
Peter
P.S.: s wird korrekt gelesen.
_________________ Zwei Worte werden Dir im Leben viele Türen öffnen - "ziehen" und "drücken".
|
|
MathiasSimmack
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: Mo 21.10.02 17:58
Hm, mal abgesehen davon, dass der Fehler bei mir z.B. nicht auftritt (und ich habe deine Zeilen 1:1 aus´m Fenster kopiert, Peter), ist das Ergebnis, dass man danach die Textzeilen samt der RTF-Formatierungssymbole sieht.
Und das wollten wir ja nun auch nicht. 
|
|
Christian S.
      
Beiträge: 20451
Erhaltene Danke: 2264
Win 10
C# (VS 2019)
|
Verfasst: Mo 21.10.02 18:29
MathiasSimmack hat folgendes geschrieben: |
Hm, mal abgesehen davon, dass der Fehler bei mir z.B. nicht auftritt (und ich habe deine Zeilen 1:1 aus´m Fenster kopiert, Peter), ist das Ergebnis, dass man danach die Textzeilen samt der RTF-Formatierungssymbole sieht.
|
Habe jetzt den Rechner komplett neu gestartet und der Fehler tritt immer noch auf. Entsprechend konnte ich auch nicht feststellen, dass es soieso nicht funktioniert.
MathiasSimmack hat folgendes geschrieben: |
Und das wollten wir ja nun auch nicht.
|
Nein, das würde wohl eher in den Beitrag über Verschlüsselung passen. Obwohl die natürlich nicht sehr effektiv wäre (was man von der dort angewandten ja aber auch nicht behaupten kann).
_________________ Zwei Worte werden Dir im Leben viele Türen öffnen - "ziehen" und "drücken".
|
|
MathiasSimmack
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: Mo 21.10.02 19:34
Peter Lustig hat folgendes geschrieben: | Nein, das würde wohl eher in den Beitrag über Verschlüsselung passen. |
Zitat: | Obwohl die natürlich nicht sehr effektiv wäre (was man von der dort angewandten ja aber auch nicht behaupten kann). |
Was meinst du?
Die von uns (dir, Wolf und mir geposteten Funktionen), oder diese "monoalphabetische Verschlüsselung" an sich? Im ersten Fall würde ich dir gern widersprechen: die Funktionen sind funktionsfähig, und oPPi hat damit 3 Möglichkeiten zur Auswahl. Wenn´s um die Methode an sich geht: na gut, es gibt bessere, aber es war ja auch nur eine Unterrichtsaufgabe.
Die Note, die oPPi kriegt, würde mich mal interessieren. 
|
|
Christian S.
      
Beiträge: 20451
Erhaltene Danke: 2264
Win 10
C# (VS 2019)
|
Verfasst: Mo 21.10.02 20:10
Nein, nein, ich meinte die monoalphabetische Verschlüsselung. Mit einer guten Häufigkeitstabelle kann man die ziemlich schnell knacken. Besonders, weil die Umlaute in diesem Beispiel nicht ersetzt werden.
MathiasSimmack hat folgendes geschrieben: |
na gut, es gibt bessere, aber es war ja auch nur eine Unterrichtsaufgabe.
|
Stimmt auch wieder ...
MathiasSimmack hat folgendes geschrieben: |
Die Note, die oPPi kriegt, würde mich mal interessieren.
|

_________________ Zwei Worte werden Dir im Leben viele Türen öffnen - "ziehen" und "drücken".
|
|