Entwickler-Ecke :: Thema anzeigen - TRichEdit: Absturz bei bestimmten Logzeilen

Entwickler-Ecke

Grafische Benutzeroberflächen (VCL & FireMonkey) - TRichEdit: Absturz bei bestimmten Logzeilen

hydemarie - Mo 13.03.17 14:28
Titel: TRichEdit: Absturz bei bestimmten Logzeilen

Mein TRichEdit [http://www.entwickler-ecke.de/topic_TRichEdit+und+UTF8_116214.html] macht mir Sorgen:

Delphi-Quelltext

1:	LogViewMemo.Lines.LoadFromFile(LogFileName, CurrentEncoding);

Funktioniert, außer mit einer Datei mit Zeilen wie dieser:

Zitat:

1981 [QUARK:3660]:[52] DEBUG 2017-02-15 15:03:50,289 - [yyyy: xxxx] - [Datei.cs].<Funktionsname>b__0(): 'blabla' für ID 'aaaaaabbbbbbcccccccddddd'

Da passiert das:

Quelltext

1:
2:
3:
4:
5:
6:
7:

---------------------------
MeinProgramm
---------------------------
Failed to Load Stream.
---------------------------
OK   
---------------------------

Warum?

Delete - Mo 13.03.17 14:42

- Nachträglich durch die Entwickler-Ecke gelöscht -

hydemarie - Mo 13.03.17 14:45

Eins nach dem anderen. :)
frDialogs steht aktuell in der Prioritätenliste hinter diesem verdammten Absturz.

Ich lese eine von C# generierte Logdatei mit Zeilen wie der zitierten aus. Das Encoding ist völlig wurst, denn es passiert in allen Encodings das Gleiche.

Delete - Mo 13.03.17 14:53

- Nachträglich durch die Entwickler-Ecke gelöscht -

hydemarie - Mo 13.03.17 15:13

Frühlingsrolle hat folgendes geschrieben :

Interessant wäre zu wissen, ob in der Zwischenzeit in die LogDatei geschrieben wird, während du versuchst diese auszulesen.

Ich habe diesen Testfall extra ausgeklammert, also die Logdatei in einen eigenen Ordner kopiert. Nein, wird sie nicht - es scheint tatsächlich an den Zeichen zu liegen. Wenn ich was rauslösche, geht es. (Habe nur noch nicht rausgefunden, welches Zeichen genau die Schuld trägt.) Die Datei durch "muuuuuuuh", "Foo Bar" usw. zu ersetzen funktioniert auch ohne Absturz.

Zitat:

Wie auch immer, ein FileStream (dazwischen) würde dir dabei helfen.

Warum? Wie? Was?

Delete - Mo 13.03.17 15:28

- Nachträglich durch die Entwickler-Ecke gelöscht -

hydemarie - Mo 13.03.17 15:34

Danke, erwäge ich für später. Aber wo kommt nun der Absturz her? :?

Delete - Mo 13.03.17 15:52

- Nachträglich durch die Entwickler-Ecke gelöscht -

hydemarie - Mo 13.03.17 16:30

Frühlingsrolle hat folgendes geschrieben :

Da ich über den Inhalt bzw. Aufbau des Logs nichts weiss, kann ich nichts genaueres sagen.

Die von mir oben reinkopierte Zeile ist theoretisch eine komplette Logdatei, die bereits abstürzt. Das Encoding scheint völlig egal zu sein. :?

Delete - Mo 13.03.17 16:52

- Nachträglich durch die Entwickler-Ecke gelöscht -

hydemarie - Mo 13.03.17 16:56

Nee, das Log ist eine .txt-Datei, erzeugt aus einem C#-Programm, das seine Klasse mitloggt. :)

Delete - Mo 13.03.17 17:06

- Nachträglich durch die Entwickler-Ecke gelöscht -

hydemarie - Mo 13.03.17 17:10

Die Logs werden nur in eine Richtung ausgegeben. Die Auswertung geschieht noch händisch - ist eher eine Art Diagnosewerkzeug.

Delete - Mo 13.03.17 17:38

- Nachträglich durch die Entwickler-Ecke gelöscht -

hydemarie - Mo 13.03.17 17:47

Was sind für ein TRichEdit denn unpassende Zeichen und warum?

Delete - Mo 13.03.17 17:58

- Nachträglich durch die Entwickler-Ecke gelöscht -

hydemarie - Mo 13.03.17 18:05

Ich war davon ausgegangen, Borlembarcadinpriscode-wasauchimmer führe zumindest eine Dokumentation darüber. Na gut, dann hilft nur Ausprobieren. Kacke.

Danke trotzdem.

hydemarie - Mo 13.03.17 21:28

Deine frDialogs löst das Problem übrigens nicht auf magische Weise. (Gibt es die auch in 64 Bit?)

Delete - Mo 13.03.17 21:35

- Nachträglich durch die Entwickler-Ecke gelöscht -

hydemarie - Mo 13.03.17 21:49

Anders: am Encoding liegt es schon mal nicht. :D

Hm, ja, gut, das würde gehen.

Delete - Mo 13.03.17 21:52

- Nachträglich durch die Entwickler-Ecke gelöscht -

jaenicke - Mo 13.03.17 21:56

hydemarie hat folgendes geschrieben :

Ich war davon ausgegangen, Borlembarcadinpriscode-wasauchimmer führe zumindest eine Dokumentation darüber.

Delphi reicht das nur an das Systemcontrol weiter. Selbst macht Delphi da gar nix. Nach Doku musst du in dem Fall bei Microsoft schauen.

hydemarie - Di 14.03.17 00:29

Frühlingsrolle hat folgendes geschrieben :

Bezogen auf dieses Thema, oder das davor?

Auf dieses. ;)
Ich meine, es kann doch nicht sein, dass ein verdammtes RTF-Feld irgendwo das Funktionieren einstellt.

hydemarie - Di 14.03.17 00:35

LogViewMemo.PlainText := True; ist schon mal keine Lösung. Weitersuchen...

Delete - Di 14.03.17 00:54

- Nachträglich durch die Entwickler-Ecke gelöscht -

hydemarie - Di 14.03.17 01:01

Nö, ist ein stinknormaler Plaintext, den ich später aber gern farblich formatieren möchte. (Was auch funktioniert - wenn die Datei nur lädt...) Deswegen dachte ich, vielleicht versucht Delphi da irgendwas RTF-Ähnliches rauszulesen. Daran lag es aber nicht.

Delete - Di 14.03.17 01:06

- Nachträglich durch die Entwickler-Ecke gelöscht -

hydemarie - Di 14.03.17 01:15

Oh-oh, ich hoffe, das sieht jetzt nicht nach "ich hab' keinen Bock, den Helfern zu helfen" aus, aber:
Das ist, fürchte ich, Firmengeheimnis. Das Logtool ist auch eher ein Hobby von mir, die Logdatei wurde mir nur von einem Kollegen (unter Vorbehalt der Datenanonymisierung) übergeben, der es auch gern beruflich nutzen würde.

Aber wenn es der Wahrheitsfindung dient (Sonderzeichen?): Anbei das defekte Log - also die Zeile von oben - mal als Datei. Genau diese Datei kann ich mit diesem Code nicht laden. edit: weg

Delete - Di 14.03.17 01:25

- Nachträglich durch die Entwickler-Ecke gelöscht -

hydemarie - Di 14.03.17 01:30

Dass der Absturz an einer anderen Stelle passiert? Hm...

hydemarie - Di 14.03.17 01:33

Nee, ist definitiv irgendein Zeichen.

Zitat:

... raised exception class EEncodingError with message 'No mapping for the Unicode character exists in the target multi-byte code page'.

Dabei ist es völlig wurscht, welches Encoding ich beim Öffnen auswähle. Und andere Dateien gehen weiterhin problemlos. :autsch:

Delete - Di 14.03.17 01:43

- Nachträglich durch die Entwickler-Ecke gelöscht -

hydemarie - Di 14.03.17 01:53

Funktioniert. :shock:

Warum?

Delete - Di 14.03.17 01:57

- Nachträglich durch die Entwickler-Ecke gelöscht -

hydemarie - Di 14.03.17 01:59

Wie verhindere ich das am Coolsten? (Encoding kenn' ich ja nun.)

Delete - Di 14.03.17 02:02

- Nachträglich durch die Entwickler-Ecke gelöscht -

hydemarie - Di 14.03.17 02:08

Dann dürfen diese Zeichen aber nicht in dieser Reihenfolge im Log auftauchen. Halte ich für schwierig.
Was ist die kompliziertere Methode?

Delete - Di 14.03.17 02:12

- Nachträglich durch die Entwickler-Ecke gelöscht -

hydemarie - Di 14.03.17 02:19

Gibt es eine Möglichkeit, das beim Einlesen zu erkennen? Dann kann ich mir den ganzen Kodierungskram sparen. 8)

Delete - Di 14.03.17 02:29

- Nachträglich durch die Entwickler-Ecke gelöscht -

hydemarie - Di 14.03.17 02:34

Hm. Gut, gibt es denn eine sinnvolle Exception, die ich da auf dem Weg irgendwo abfangen könnte?
(Also: Versuch UTF8 - wenn Fehler, versuch ASCII - wenn Fehler, versuch ANSI - ...).

Delete - Di 14.03.17 02:40

- Nachträglich durch die Entwickler-Ecke gelöscht -

hydemarie - Di 14.03.17 02:42

Keinen Stress, du kommst ja zu nix anderem mehr als meine doofen Fragen zu beantworten. :zustimm:

hydemarie - Di 14.03.17 02:47

Ulkige Idee bzw. was funktioniert: TMBCSEncoding.
Mal basteln.

Delete - Di 14.03.17 02:51

- Nachträglich durch die Entwickler-Ecke gelöscht -

hydemarie - Di 14.03.17 02:54

Hübsch, klingt aber, als wäre es bei einem Logviewer, der quasi dauernd das Log nachlädt, wenn es pausenlos weiter beschrieben wird, etwas unpraktisch.

Delete - Di 14.03.17 02:56

- Nachträglich durch die Entwickler-Ecke gelöscht -

hydemarie - Di 14.03.17 02:59

Das Encoding für das aktuelle "Form" ändert sich ja nicht dauernd. Das kann man ja beim ersten Mal direkt speichern.

hydemarie - Di 14.03.17 03:02

Scheint nur bedingt zu funktionieren.

Delphi-Quelltext

1:	OpenFile(FilesToOpen[i], TMBCSEncoding.Create(LastStoredEncoding));

Alles bestens, wenn der int = 65001 und die Datei eine Unicodedatei ist. An ASCII-Dateien beißt sich TMBCSEncoding mit jeder übergebenen Zahl die Zähne aus. Auch 1252, obwohl 1252 eigentlich stimmen sollte. Ich schlafe mal drüber. (Bin voraussichtlich auch erst Mittwoch wieder fähig, dran zu arbeiten. Pardon!)

Delete - Di 14.03.17 03:08

- Nachträglich durch die Entwickler-Ecke gelöscht -

hydemarie - Di 14.03.17 03:12

Wenn es denn funktionieren würde. Aber ASCII ist halt keine Multi-Byte-Kodierung ...

Was tun?

Gute Nacht erst mal.

jaenicke - Di 14.03.17 07:51

Muss es denn ein TRichEdit sein? Mit einem simplen TMemo gibt es in der Regel weniger Probleme.

Und um eine ganz andere Implementierung zu haben, wäre auch noch SynEdit eine Idee. Vor allem, wenn im Log etwas syntaktisch hervorgehoben werden soll (was ich wegen TRichEdit vermute?).

hydemarie - Di 14.03.17 10:16

Ich möchte für zwei Dinge eine Möglichkeit zur einfachen Formatierung haben:

1) Livesuche im aktuellen Fenster.
2) Farbliche Kennzeichnung von bspw. DEBUG-Zeilen.

Und zwar gleichzeitig.

Mit TRichEdit geht das. :?

t.roller - Di 14.03.17 12:24

CurrentEncoding allein reicht als Parameter nicht aus.

Mit folgendem Code funktioniert es bei mir:

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:

procedure TForm1.ButtonClick(Sender: TObject);
var
  Encoding : TEncoding;
  EncIndex : Integer;
begin
    EncIndex := OpenTextFileDialog1.EncodingIndex;
    Encoding := OpenTextFileDialog1.Encodings.Objects[EncIndex] as TEncoding;

if OpenTextFileDialog1.Execute then
    RichEdit1.Lines.LoadFromFile(OpenTextFileDialog1.FileName, Encoding);
end;

jaenicke - Di 14.03.17 13:17

hydemarie hat folgendes geschrieben :

1) Livesuche im aktuellen Fenster.
2) Farbliche Kennzeichnung von bspw. DEBUG-Zeilen.

Für beides benutze ich ein TSynMemo. Das ist sehr schnell und noch dazu auch dafür gedacht, während du beim TRichEdit die Zeilen erst markieren und deren Attribute ändern musst. Bei SynEdit gibt es dafür schlicht das Event OnSpecialLineColors, in dem ich die Farben nur setzen muss.

hydemarie - Di 14.03.17 13:49

SynEdit wollte ich extra nicht unbedingt nutzen, hatte da Performancebedenken (externe Bibliotheken klingen immer nach Extrarechenaufwand). Wie gut kommt ein SynMemo mit einer 10-Megabyte-Datei klar? (Das ist so das avisierte Maximum.) - Nachtrag: Mbyte, nicht kbyte, natürlich.

Zitat:

CurrentEncoding allein reicht als Parameter nicht aus.

Danke!

jaenicke - Di 14.03.17 13:58

Ähm... SynEdit ist deutlich schneller als TRichEdit, weil du bei TRichEdit durch die Attribute usw. einen relativ hohen Overhead hast...

Eine 3,5 MiB Delphiquelltextdatei (eine importierte Typbibliothek ;-)) wird hier inkl. Syntaxhighlighting in nicht einmal 100 Millisekunden geladen und angezeigt. ;-)

Delete - Di 14.03.17 14:08

- Nachträglich durch die Entwickler-Ecke gelöscht -

jaenicke - Di 14.03.17 14:28

Wir benutzen Synedit auch unter 10.1 Berlin. Ich habe die Synedit Units aber in unser eigenes Komponentenpackage integriert um nicht bei jeder neuen Delphiversion so viele Package installieren zu müssen.

Zudem gibt es auch für 10.1 Berlin offizielle Packages. Siehe Repository:
https://github.com/SynEdit/SynEdit

Delete - Di 14.03.17 14:43

- Nachträglich durch die Entwickler-Ecke gelöscht -

hydemarie - Di 14.03.17 16:08

Dann muss ich ja mein ganzes Highlighting neu einstellen. :roll: :wink:

Danke, dann habe ich den Rest der Woche ja etwas zu tun...
Im vorliegenden Fall hat das Delphiprogramm beim Dateiladen jedenfalls sehr lange nicht mal reagiert.

Delete - Di 14.03.17 16:23

- Nachträglich durch die Entwickler-Ecke gelöscht -

hydemarie - Di 14.03.17 18:14

Ich dachte immer, ich müsste dafür eine komplette neue Syntax entwerfen und einbauen, auch, wenn ich eigentlich nur drei oder vier Begriffe "finden" will. Wieder was gelernt.

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!