Autor |
Beitrag |
jahuer1
Beiträge: 39
|
Verfasst: Do 08.09.05 15:06
Problem mit Delphi 8:
Plötzlich wird irgend eine Datei, die in ein TRichEdit geladen wird, in japanischen Zeichen dargestellt!
Ich habe einfach mal das banalste aller Beispiele zusammengeklickt - es passiert:
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35:
| unit Unit4;
interface
uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, Borland.Vcl.StdCtrls, System.ComponentModel, Borland.Vcl.ComCtrls;
type TForm4 = class(TForm) re: TRichEdit; Button1: TButton; OpenDialog1: TOpenDialog; procedure Button1Click(Sender: TObject); private public end;
var Form4: TForm4;
implementation
{$R *.nfm}
procedure TForm4.Button1Click(Sender: TObject); begin if opendialog1.execute then re.lines.Loadfromfile(opendialog1.filename); end;
end. |
Und zwar flackert der richtige Text kurz auf, dann wird alles in japanischen/chinesischen Zeichen dargestellt (Dort steht natürlich dann totaler Schrott!).
Mit Delphi 7 sowie mit VB.NET (Visual Studio) habe ich keine Probleme.
Hinweis: Die Zeichensätze sind auf meiner Maschine installiert.
Hat einer eine Idee, was da falsch läuft?
Moderiert von Christian S.: Code- durch Delphi-Tags ersetzt.
|
|
demo88
Beiträge: 160
Ubuntu 6.04, Win XP
Delphi 7
|
Verfasst: Do 08.09.05 21:05
Erstens: Japanische zeichen sind kein Schrott
Zweitens: Ich bin mir nicht sicher aber guck mal im Objektinspektor unterm Richedit. Da könnte doch irgendwas von wegen Zeichen und so stehen
_________________ "Das ist kein Bug, das ist ein Feature..."
|
|
jahuer1
Beiträge: 39
|
Verfasst: Fr 09.09.05 09:50
boku wa nihongo mou dekimasu you! - Oder: Ich kann sehr wohl lesen, was dort steht! Aber es ist auch sonst einsichtig, dass wenn einfach ASCII-Zeichen aus einer anderen Sprache zusammengefasst und als Kanji interpretiert werden, wohl nicht ganz was tolles rauskommt.
Um gerade Probleme mit alten Einstellungen von irgendwoher zu vermeiden, habe ich ja ein neues Dummy-Projekt gemacht! Alles mit Orginaleinstellung. Dort steht auch unter Font.CharSet frisch fröhlich ANSI_CHARSET
Zur Erinnerung: Der korrekte Text flackert zuerst kurz (ev. 1 Zehntelsekunde) auf. Erst dann wechselt der Font.
Also: Eine zündende Idee ist gefragt.
|
|
Holgerwa
Beiträge: 325
WIN XP Pro, Vista Business
Delphi 7 Pro, BDS 2006 Pro
|
Verfasst: Fr 09.09.05 10:36
Hallo,
um mal einzukreisen, ob es in irgendeiner Art am Delphi liegt oder an Windows:
Was passiert, wenn Du die .exe Datei auf einem anderen Computer laufen läßt?
Holger
|
|
jahuer1
Beiträge: 39
|
Verfasst: Fr 09.09.05 15:10
Hmmm,
Es kommt offenbar nicht darauf an, auf welcher Maschine man ist, noch auf das Betriebssystem... (XP vs 2000).
Es geht offenbar um das Format der (RTF-)Datei - oder viel mehr wohl, welche Tags am Anfang stehen. Ich habe jetzt nämlich ein älteres RTF genommen. Dort funktionierts einwandfrei.
Jedoch: Ich habe auch noch weitere, zufällige Dateien (TXT, PAS, ... - was so theoretisch lesbar ist) genommen. Hier funktionierts wiederum nicht!
Ich fände es noch einsichtig, wenn irgendwo in einem der nicht-funktionierenden RTF's ein falscher Tag steht. Aber warum funktionierts bei TXT's etc. ebenfalls nicht
|
|
Holgerwa
Beiträge: 325
WIN XP Pro, Vista Business
Delphi 7 Pro, BDS 2006 Pro
|
Verfasst: Fr 09.09.05 15:27
Hallo,
Du hast also:
- "neue" RTF-Dateien, die den Fehler zeigen
- "alte" RTF-Dateien, die den Fehler nicht zeigen
- wenn Du wahllose Texte mit dem Programm öffnest, und diese dadurch in RTF umwandelst, woraus wiederum angenommen eine "neue" RTF-Datei entsteht, zeigt sich der Fehler wieder.
Mach doch mal folgendes:
Wenn Du diese "alte" RTF-Datei lädst, wird sie korrekt angezeigt. Wandle diese Datei mal in einen normalen Text um, und öffne diese Text-Datei dann wieder mit Deinem Programm.
Das Ergebnis sollte sein, daß sich der Fehler wieder zeigt, da dies genau das ist, was Du mit den anderen Textdateien gemacht hast.
Jetzt vergleich die beiden RTF-Dateien, die ja den gleichen Text beinhalten, aber ziemlich sicher irgendwelche unterschiedlichen RTF-Tags.
Da sollte sich doch herausfinden lassen, welche Unterschiede das eine oder andere Verhalten verursachen.
Das könnte doch weiterhelfen, wenn man erstmal die Verursacher findet.
Holger
|
|
jahuer1
Beiträge: 39
|
Verfasst: Fr 09.09.05 16:19
Titel: Erster Unterschied
Ich habe einen Unterschied gefunden! Und zwar: Ich habe mir mal die Tags in der "fehlerhaften" RTF-Datei strukturiert dargestellt (im Notepad).
Folgende Variante geht nicht:
Quelltext 1: 2: 3: 4: 5:
| {\rtf1\ansi\ansicpg1252\uc1 \deff0\deflang1033\deflangfe1033 {\fonttbl{\f0\froman\fcharset0\fprq2 {\*\panose 02020603050405020304}Times New Roman;} {\f2\fmodern\fcharset0\fprq1 ... |
Folgende Variante geht :
Quelltext 1: 2: 3: 4: 5:
| {\rtf1\ansi\ansicpg1252\uc1 \deff0\deflang1033\deflangfe1033 {\fonttbl{\f0\froman\fcharset0\fprq2 {\*\panose 02020603050405020304}Times New Roman;} {\f2\fmodern\fcharset0\fprq1 ... |
- Die Datei mit dem kleinen Unterschied : Vor steht ein Space
Fragt mich bitte nicht warum, aber so gehts!
Vielleicht hat ja jemand eine gescheite Idee dafür? Meines Wissens ist die erste Variante nach RTF-Definition nicht illegal. Zudem funktioniert mein altes RTF auch ohne diesen Space...
Und dann bleibt immer noch das Problem, dass TXT's auch nicht funktioniert haben.
|
|
alias5000
Beiträge: 2145
WinXP Prof SP2, Ubuntu 9.04
C/C++(Code::Blocks, VS.NET),A51(Keil),Object Pascal(D2005PE, Turbo Delphi Explorer) C# (VS 2008 Express)
|
Verfasst: Fr 09.09.05 18:00
Dann würde mich glatt nochwas interessieren. Wie sieht das bei anderen D8-Usern aus? Könnte ein D8 Bug sein oder nicht? Gehts in D2005, wenn du hast?
|
|
|