Buchstabensalat im Source (Delphis Beispiele)

[Harry Stahl]

Bei den von Delphi mitgelieferten Beispielen steht z.T. Buchstabensalat dort, wo Kommentare stehen sollten, siehe anliegenden Screenshot (stammt aus dem Hauptformular des Beispiels "Shaderfilters").

Wieso ist das so und kann man das vermeiden?

[Redeemer]

Das ist vermutlich Kyrillisch. Die Dokumente wurden in ANSI abgespeichert, auf einem System, auf dem ANSI etwas anderes als bei dir ist. Auf westlichen PCs ist ANSI=Windows-1252.

[t.roller]

Das Beispiel gibt es auch in Englisch:

Delphi-Quellcode:

procedure TfrmMain.listFX1Click(Sender: TObject);
var
  i: integer;
  Item: TListboxItem;
  Shape: TSelectionPoint;
begin
  if (TransitionAni <> nil) and (TransitionAni.Running) then
    TransitionAni.Stop;

  if listFX.ItemIndex < 0 then Exit;
  // Delete setting controls
  if TransitionAni <> nil then
    FreeAndNil(TransitionAni);
  Dest.DeleteChildren;
  panelSettings.Clear;
  // Create Filter
  if Filter <> nil then
    Filter.Free;
  Filter := FilterByName(listFX.ListItems[listFX.ItemIndex].Text);
  // Create settings
  Rec := FilterClassByName(listFX.ListItems[listFX.ItemIndex].Text).FilterAttr;
//  labelName.Text := Rec.Desc;
....

https://sourceforge.net/p/radstudiod...pas?format=raw
oder alles:
https://sourceforge.net/p/radstudiod...RadStudio_XE2/

Ist zwar für XE2, aber in BERLIN bzw. TOKYO sicher brauchbar.

[Harry Stahl]

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

[nahpets]

Quelltext schreibt man in der Sprache Delphi.

Kommentare in der Muttersprache.

Die Zeichensätze haben übereinstimmende Teilmengen und halt noch die der jeweiligen Muttersprache der Programmierer (oder was halt sonst auf dem System eingestellt ist).

Delphiquelltext benutzt halt überall den von der Programmiersprache vorgesehenen Zeichensatz, der ja auch nicht vollständig unserem Zeichensatz entspricht. Kommentare von uns mit äöü ... sehen andernorts auch kryptisch aus.

Oder anders: Die Übereinstimmung unserer Schrift mit der der Programmiersprache ist (zufällig) recht hoch, für andere Sprachen und Schriften sieht das anderrs aus, da gibt es entweder wenige oder auch garkeine Übereinstimmung. Und das sieht man halt an allem, was der Compiler nicht zu verstehen braucht.

[t.roller]

Zitat:

Zitat von nahpets (Beitrag 1380959)

Oder anders: Die Übereinstimmung unserer Schrift mit der der Programmiersprache ist (zufällig) recht hoch,...

Ein Zufall ist das nicht:
Im 4.Jahrhundert zerfiel das Römische Reich, ca. 400 000 Römer verließen fast alle Britannia. Dann kamen Angeln und Sachsen.
Die Sprache der Einwanderer und die Sprache der Germanen entwickelten sich in den letzten 1600 Jahren getrennt weiter - beeinflusst von GRIECHISCH, LATEIN (RÖMISCH), FRANZÖSISCH.
Vielleicht redet man in Germany in 100 Jahren nur noch ENGLISH...

[nahpets]

Naja, mit dem Zufall meinte ich das so, dass unsere Schriftsprachen Übereinstimmungen mit der Sprache hat, auf der Delphi basiert.

Für den weitaus größten Teil der Menschheit dürfte dies nicht zutreffen.

Gäbe es eine Programmiersprache, die z. B. auf der japanischen Sprache und der japanischen Schriftsprache basiert, könnten wir halt unsere Kommentare lesen, aber der "Rest" sähe (erstmal) kryptisch aus.

Das dürfte bei Sanskrit, Kyrillisch, Griechisch, Chinesisch, ... halt ähnlich sein.

Die Leute dort müssen, neben der Programmiersprache auch erstmal eine neue Schrift (mit eher ungewohnten Zeichen) lernen. Für Kommentare können sie ihre eigene Schriftsprache nutzen.

[Uwe Raabe]

Zitat:

Zitat von nahpets (Beitrag 1380959)

Quelltext schreibt man in der Sprache Delphi.

Oh, da kenne ich aber so manchen Spezialisten, der mal eben ein paar Bezeichner mit Umlauten einfließen lässt - was in Delphi durchaus erlaubt ist. Auch Namen der Komponenten können aus mehr als nur Standard-ASCII Zeichen bestehen und auch die tauchen ja im Interface Teil der Form-Unit namentlich auf. Insofern können wir schon froh sein, daß lediglich die Kommentare in Kyrillisch sind.

Delphi-Quellcode:

type
  TPaßform = class(TForm)
    Hauptmenü: TMainMenu;
    HübscheBildchen: TImageList;
    Großbaustelle: TMenuItem;
    KurzDöser: TTimer;
    Maßeingabe: TComboBox;
    procedure KurzDöserTimer(Sender: TObject);
  private
  public
  published
  end;

[nahpets]

Das mit den Umlauten ist aber auch "neu", mein olles Delphi 7 haut mir das noch um die Ohren.

Aber unsere Eltern und Großeltern haben noch Sütterlin gelernt.
Die Eltern konnten beides, Sütterlin und unsere heutige Schriftsprache, bei den Großeltern war diese "Zweisprachigkeit" nicht zwingend gegeben, bzw. nur beim Lesen, das Schreiben war schon schwieriger.

Unsereins hat am Anfang in der Volksschule auch noch beides lernen dürfen, aber nur in den ersten zwei Schuljahren. (Aber davon ist nix übriggeblieben ;-))

Wäre aber nett zu wissen, ob man beim heutigen Delphi Kommentare auch in Sütterlin schreiben kann ;-)

[Delphi-Laie]

Zitat:

Zitat von nahpets (Beitrag 1380961)

Die Leute dort müssen, neben der Programmiersprache auch erstmal eine neue Schrift (mit eher ungewohnten Zeichen) lernen.

Das dürfte mit dem Englischunterricht erledigt sein. Dieser ist nahezu weltweit gegeben. Zur Not tut es auch das Erlernen einer anderen europäischen Schriftsprache, die auf dem lateinischen Alphabet beruht.

Zitat:

Zitat von nahpets (Beitrag 1380961)

Für Kommentare können sie ihre eigene Schriftsprache nutzen.

Weiß jemand, wie das geschieht?

Muß man ständig den Tastaturtreiber wechseln, wenn man von echtem Quellcode auf eigensprachliche Kommentare und dann zurückwechselt? (In Windows 2000 und XP gibt es ja dieses ominöse blaue DE-Symbol, das ich nach jeder Windows-Installation irgendwie wegputze).

Falls man immer umschalten muß, wäre das wirklich lästig. Welch ein Glück, daß Deutsch und Englisch sich so sehr ähneln.

Edit: Das Ding hat den hochtrabenden Namen "Eingabegebietsschemaleiste" und kann über die Symbolleisten ein- und ausgeblendet werden.

[Redeemer]

Das mit den Bezeichnern geht seit D2005.

Zitat:

Zitat von nahpets (Beitrag 1380963)

Wäre aber nett zu wissen, ob man beim heutigen Delphi Kommentare auch in Sütterlin schreiben kann ;-)

[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).

[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.

[t.roller]

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

[Capstone]

Zitat:

Zitat von nahpets (Beitrag 1380963)

Das mit den Umlauten ist aber auch "neu", mein olles Delphi 7 haut mir das noch um die Ohren.

Hi,
man kann Dich ja leider nicht per PN erreichen, darum muß ich hier fragen:
Ich nutze nämlich auch noch Delphi 5 - zum Leidwesen aller anderen Programmierer im internet, wie mir scheint.
Daß meine HelloWorld-Programme deutlich unter 2 MB groß sind [380 KB] ist in Zeiten von Terabytes und Petabytes leider uninteressant.

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]
Leider muß ich auch auf Hilfen wie ByteStream oder StringReplace verzichten. Naja.

Zitat:

Zitat von Harry Stahl (Beitrag 1380859)

Bei den von Delphi mitgelieferten Beispielen steht z.T. Buchstabensalat [...]

ä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?

°= Pro/Enterprise/Archi

[Der schöne Günther]

Zitat:

Zitat von t.roller (Beitrag 1380972)

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

Toll, danke, wieder was gelernt.

[t.roller]

Ich habe mal UTF-8 getestet.
Nachträglich kann man falsch decodierten Text nicht mehr ändern.

// Falsch decodiert:
// Îñòàíàâëèâàåì àíèìàöèþ äëÿ ýôôåêòîâ ïåðåõîäà
// Beispiel Russisch:
// Описание журнала = Beschreibung der Zeitschrift

[Uwe Raabe]

Zitat:

Zitat von t.roller (Beitrag 1380978)

Ich habe mal UTF-8 getestet.
Nachträglich kann man falsch decodierten Text nicht mehr ändern.

Dazu müsstest du erst dein Windows so ändern, daß als ANSI Codepage Kyrillisch 1251 eingestellt ist. Dann kannst du die Datei öffnen und der Text kommt auch lesbar rüber (verstehen kann ich ihn dennoch nicht :stupid:).

Der Editor in der IDE verwendet immer Unicode. Lediglich beim Laden und Speichern kommt das eingestellte Format zum tragen. Ist der Text erstmal falsch dekodiert worden, weil die CodePage nicht passt, dann ist das im Unicode nicht mehr zu reparieren.

[uligerhardt]

Zitat:

Zitat von t.roller (Beitrag 1380978)

Ich habe mal UTF-8 getestet.
Nachträglich kann man falsch decodierten Text nicht mehr ändern.

Doch. :mrgreen:
Ich hab mal dein "Îñòàíàâëèâàåì àíèìàöèþ äëÿ ýôôåêòîâ ïåðåõîäà" nach Notepad++ kopiert und dort Kodierung->Zeichensatz->Kyrillisch->Windows-1251 ausgewählt.
Ergebnis: "Останавливаем анимацию для эффектов перехода", laut Google Translator "Stop the animation for transition effects".

[t.roller]

Toll, das hätte ich nicht gedacht.
Grund:
Kyrillische Zeichen sowie Zeichen fernöstlicher Sprachen und von Sprachen aus dem afrikanischen Raum belegen bis zu 4 Byte je Zeichen.
https://de.wikipedia.org/wiki/Windows-1251
https://de.wikipedia.org/wiki/UTF-8

Nebenbei bemerkt:
Eine Umstellung im DELPHI-Editor ändert auch die Kürzel - siehe Anhang.

[Bernhard Geyer]

Zitat:

Zitat von Harry Stahl (Beitrag 1380957)

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:

Zitat von Harry Stahl (Beitrag 1380967)

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:

Zitat von Harry Stahl (Beitrag 1380967)

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:

Zitat von Capstone (Beitrag 1380973)

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:

Zitat von Capstone (Beitrag 1380973)

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:

Zitat von Capstone (Beitrag 1380973)

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:

Zitat von Capstone (Beitrag 1380973)

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:

Zitat von Capstone (Beitrag 1380973)

ä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:

Zitat von t.roller (Beitrag 1380972)

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:

Zitat von t.roller (Beitrag 1380972)

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:

Zitat von Harry Stahl (Beitrag 1381087)

Ü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:

Zitat von Redeemer (Beitrag 1380969)

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:

Zitat von Harry Stahl (Beitrag 1381090)

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:

Zitat von Harry Stahl (Beitrag 1380967)

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. :stupid:

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.