Buchstabensalat im Source (Delphis Beispiele)

[Bernhard Geyer]

Zitat von Harry Stahl:

OK, aber warum bestehen nur die auskommentierten Zeilen aus diesem Buchstabensalat, die "normalen" Source-Code-Zeilen aber nicht?

Weil der Quellcode nur Zeichen von $20 - $7F beinhaltet.
Dieses sind (für ANSI) immer gleich. Erst ab $80 wird die entsprechene Codepage eineblendet.

Zitat von Harry Stahl:

Wäre es da denn nicht sinnvoller, die Texte direkt im Unicode-Format zu erstellen?

Du hast in aktuellen Delphi-Versionen die freie wahl

Zitat von Harry Stahl:

aber die Delphi-Quelltexte sind standardmäßig immmer noch in ANSI (ebenso die Formular-Dateien).

Einfach ohne Not das zu ändern kann bei diversen Quellcodeverwaltungssystemen ziemlich in die Hose gehen.
Die Formulardateien brauchen nicht geändert werden da diese schon seit D5 (?) Unicodetexte speichern können.

[Bernhard Geyer]

Zitat von Capstone:

Ich nutze nämlich auch noch Delphi 5 - zum Leidwesen aller anderen Programmierer im internet, wie mir scheint.

Du kannst nutzen was du willst, beschwer dich aber nicht darüber das mit einer solchen Version manches nicht geht.

Zitat von Capstone:

Daß meine HelloWorld-Programme deutlich unter 2 MB groß sind [380 KB] ist in Zeiten von Terabytes und Petabytes leider uninteressant.

Ist absolut uninteressant. Für die meisten Entwickler ist es wichtiger das man mit neueren IDE-Versionen produktiver arbeiten kann und z.B. auch nativen Unicode hat oder 64-Bit Programme erstellen kann. Wenn ein Kunde was beauftragt und ich sage "Könnte das für 8000 € mit einer 8MB-Exe machen oder für 12000 € und einer 2 MB-Exe werden werden 99,9% der Kunden die 8MB-Version wählenn.

Zitat von Capstone:

Gibt es da was zum "nachrrüsten" [ich möchte nicht die 24 GB große Berlin Starter Edition installieren - mein D5 hat 67 MB in C:\Program Files (x86)\Borland\Delphi5]

Du kannst versuchen mit FreePascal zum ziel zu kommen. Nachrüsten lässt sich für solche antiken Versionen wenig (TNT-Controls für Unicode-Support). Neues gibt dafür nicht mehr.

Zitat von Capstone:

Leider muß ich auch auf Hilfen wie ByteStream oder StringReplace verzichten. Naja.

Es gibt bei MS (teilweise gut Versteckt) installer welche die Uralte WinHelp-Hilfe nachrüsten.

Zitat von Capstone:

äh, also obwohl ich von ner Firma eine IDE für fast 1920 bis 4000/8000€ [also in DM wären das so ca. 3000/8000,-° bis 16.000 DM gewesen, falls noch wer ... D-Mark kennt] kaufe, muß ich mir dennoch Übersetzungen der mitgelieferten Quellcodedateien aus dem Internet Translatergooglen?

Wie angemerkt gibt diese Beispiele auch mit englichen Kommentaren. Hier müsste die Manager dafür sorgen das Quellcodekommentare immer in Englisch erstellt werden.

[Uwe Raabe]

Zitat von t.roller:

Wer was Anderes braucht, kann es einstellen - siehe Anhang.

Ich bin mir nicht sicher, ob das irgendeinen Einfluss auf die Codierung hat die vom Quelltexteditor verwendet wird. Ich vermute (nicht probiert), daß es lediglich die Codierung ist, mit der die UML-Modellierung ihre Quelltextdateien erzeugt. Da ich aber die Modellierung innerhalb der IDE nicht benutze (habe dafür ein anderes Tool), kann ich das nicht mit Sicherheit sagen.

[Harry Stahl]

Zitat von t.roller:

Wer was Anderes braucht, kann es einstellen - siehe Anhang.

Aber ich denke, das gilt nur für die "Modellierung". Denn wenn ich an der von Dir vorgeschlagenen Position auf UT8 umstelle und ein neues Projekt anlege, dann sind dennoch alle Dateien in ANSI.

Erst wenn ich explizit per Rechtsklick in den Source-Code, Befehl "Dateiformat" auf UTF8 umstelle (siehe Anlage) wird der Text auch in UTF8 gespeichert.

Also letztlich würden von Anwendern, welche ihre Kyrillischen Kommentare im UTF8-Format erstellen diese auch auf meinem in D laufenden PC richtig dargestellt. Insofern wäre es schon sinnvoll, wenn EMBA Demo-Dateien mit kyrillischen Kommentaren ausliefert, dass die Source-Dateien dann in UTF8 sind, statt in ANSI.

Dann hätte man zumindest noch die Chance per Google-Translate (wie hier etwas später im Thread angesprochen) ermitteln zu können, wie der Kommentar lautet.

Übrigens: Wenn ich die übersetzten kyrillischen Zeichen im Ansi-Text einbette, bietet mir Delphi an, den Text in UTF8 zu speichern, damit Zeichen nicht verloren gehen.

Also warum nicht gleich alles in UTF8, dann kann man sich diese ganze Problematik sparen.

[Redeemer]

Zitat von Harry Stahl:

Übrigens: Wenn ich die übersetzten kyrillischen Zeichen im Ansi-Text einbette, bietet mir Delphi an, den Text in UTF8 zu speichern, damit Zeichen nicht verloren gehen.

Also warum nicht gleich alles in UTF8, dann kann man sich diese ganze Problematik sparen.

Ich schrieb bereits:

Zitat von Redeemer:

Delphi nimmt ANSI, sofern alle Buchstaben in deiner derzeit verwendeten ANSI-Codepage liegen. Ansonsten wirst du gefragt, ob du UTF-8 nehmen möchtest. Man kann das natürlich auch einstellen, dass immer UTF-8 genommen wird.

Kyrillisch ist nicht deine derzeit verwendete ANSI-Codepage, also fragt Delphi wegen UTF-8.

[Harry Stahl]

Aber wo kann man das einstellen? Was hier gezeigt wurde, gilt für die Modellierungs-Funktion, aber wohl nicht für den Editor.

[Aviator]

Zitat von Harry Stahl:

Aber wo kann man das einstellen? Was hier gezeigt wurde, gilt für die Modellierungs-Funktion, aber wohl nicht für den Editor.

Das wollte ich auch mal wissen, weil ich bestimmt nicht jedes Mal daran denke, das umzustellen. Habe überall danach gesucht. Irgendwo hatte ich mal einen Ansatz gefunden. Der hatte aber soweit ich das noch in Erinnerung habe nicht funktioniert. Das Ende vom Lied war, dass man den Standard nicht umstellen kann und immer ANSI genommen wird.

Finde ich auch ziemlich doof. SourceTree bspw. hat nämlich damit so seine Probleme wenn ich in Beschreibungen von Methoden Umlaute verwende wenn es auf ANSI eingestellt ist. Auf UTF8 gibt es da keine Probleme.

[himitsu]

Zitat von Harry Stahl:

Wäre es da denn nicht sinnvoller, die Texte direkt im Unicode-Format zu erstellen? Alles dreht sich inzwischen um Unicode (z.B. UTF-8), aber die Delphi-Quelltexte sind standardmäßig immmer noch in ANSI (ebenso die Formular-Dateien).

Standardmäßig "nein".

Schon seit Jahren wirst du von Delphi gefragt, wenn du eine Unit speicherst und dort nicht alle Zeichen in die aktuelle Codepage passen.
Aber ja, einfach immer gleich als UTF-8 gespeichert sorgt für weniger Problemchen.

Genauso wie TextDFMs schon seit Jahren für mehr Freude in Versionssystemen bereiten, gegenüber den BinärDFMs.



In diesem Fall die Datei mit einem Texteditor öffnen, dabei eine passende Codepage auswählen und das dann wieder als UTF-8 abgespeichert, schon ist der Salat weg, auch wenn Viele es dann dennoch nicht lesen können.

Du kannst auch TStringList nehmen, beim Laden die gewünschte Codepage (TEncoding) mitgeben und anschließend mit TEncoding.UTF8 wieder abspeichern.

[Redeemer]

Ich meinte damit, dass man per Rechtklick auf den Editor das umstellen kann, dass die aktuelle Unit UTF-8 benutzt.