Kann WSImgList nicht finden

[mh18058]

Hallo,
ich portiere gerade ein Delphi-Projekt nach Lazarus und erhalte beim Kompilieren des Projekts die Fehlermeldung:
imglist.pp(475,3) Fatal: Kann WSImgList nicht finden verwendet von ImgList, inkompatible ppu=C:\lazarus\lcl\units\x86_64-win64\wsimglist.ppu, Package LCLBase
siehe Anhang "WSImglist-Fatal#1.JPG"

Die Datei "wsimglist.ppu" ist im Verzeichnis "C:\lazarus\lcl\units\x86_64-win64\" vorhanden,
siehe Anhang "WSImglist-Fatal#4.JPG" oben.

Ein Hint auf der Fehlermeldung lautet:
"You tried to use a unit of which the PPU File isn't found by the
compiler. Check your configuration file for the paths."

Meine Pfade sind in Anhang "WSImglist-Fatal#4.JPG" unten zu sehen.

Weil es sich offensichtlich um das Package LCLBase handelt, sollte der Pfad doch bereits bekannt sein und braucht nicht extra angegeben zu werden.
Ich hab´s aber trotzdem mal unter "andere Units" angegeben und die IDE mit "Alle aufräumen" neu kompiliert.
Die obige Fehlermeldung bleibt jedoch erhalten.
Ich verwende die Lararus-IDE 2.2.0 mit FPC 3.2.2 64bit unter Windows-10 64bit.
Der Versuch mit Lararus-IDE 2.2.0 mit FPC 3.2.2 32bit ergab die gleiche Fehlermeldung.
Der Versuch mit Lazarus 2.0.8 FPC 3.0.4 64bit ergab auch die gleiche Fehlermeldung.

Das configuration file "C:\lazarus\fpc\3.2.2\bin\x86_64-win64\fpc.cfg" hab´ ich als txt-Datei auch mal angehängt.
Ich kann da aber keinen Fehler feststellen.
Allerdings erscheint in der Rubrik "# Set Filenames and Paths" z.B. der von mir angegebene Pfad auf die Unit NiceGrid auch nicht, was mich verwundert.
Jedoch wurde NiceGrid gefunden und auch einwandfrei kompiliert.

Natürlich hab´ ich nach WsImglist usw. gegoogelt, aber leider keinen brauchbaren Hinweis gefunden.
Die beiden Beiträge hier im Forum zum Suchbegriff "WSImglist" helfen leider auch nicht weiter.

Jetzt weiß ich nicht mehr weiter und stecke grandios fest!
Wäre toll , wenn mir in der Sache jemand auf die Sprünge helfen könnte ...

Gruß
Martin

[theo]

Aber ein neues Projekt (nicht dein Delphi Import) läuft?
Wie hast du importiert?
Über "Werkzeuge -> Delphi Umwandlung"?

[wp_xyz]

Die Suchpfade für "Andere Units" und "Include-Dateien" sind für Units, die von Lazarus verwendet werden, normalerweise absolut tabu. Denn wenn dein Projekt eine von diesen Units übersetzt, muss es auch weitere Units übersetzen, die es aber nicht findet, weil die Pfade nicht bekannt sind.

Ich weiß, in Delphi macht man das so. Da packt man alle Bibliotheken in einen ewig langen Suchpfad. Lazarus dagegen arbeitet mit Packages. Du musst die benötigten Packages in der Packageliste des Projekt-Inspektors eintragen. Dann weiß Lazarus, welche Packages verwendet werden, und jedes Package weiß, wo es seine Units findet.

Also: Lösche c:\lazarus\lcl aus den "anderen Units" und lösche alles mit "C:\lazarus" vorne aus den Include-Dateien. Öffne "Projekt" > "Projektinspektor". In dem Baum klicke auf "Benötigte Packages": Ist da LCL aufgeführt? Wenn nicht, "Hinzufügen" > "Neue Anforderung"; suche "LCL" in der Liste, anklicken, "OK"; nun ist LCL in der Packageliste des Projektes.

Lösche das bisher angelegte Projekt-Ausgabeverzeichnis (lt Screenshot ist das das Unterverzeichnis "lib" im Projektordner). Dadurch verschwinden die LCL-Units die evtl. dort gelandet sind und die Wurzel des Übels sind. Das Ausgabeverzeichnis darf nur die übersetzten Units deines Projektes enthalten, aber nicht die von benutzten Lazarus-Packages oder von Packages dritter.

Versuche nun das Projekt zu kompilieren. Vielleicht hat das schon gereicht.

Eine weitere Fehlerquelle beim Import von Delphi ist die Projekt-Datei .lpr: In der Unitliste muss vorne die Unit "Interfaces" aufgeführt sein, sonst funktioniert das Widgetset-System nicht. Ein üblicher Kopf ist

Code: Alles auswählen

uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Interfaces, // this includes the LCL widgetset    // <---- WICHTIG: das darf bei einem LCL-Programm nicht fehlen
  ...

wobei der mit IFDEF geklammerte Bereich wegfallen kann, wenn du definitiv nicht mit Linux und Threads arbeitest.

Noch ein Wort zu dem NiceGrid. Ich kenne das nicht, aber ich bezweifle, dass es ohne weiteres unter Lazarus funktioniert. Die Portierung von Delphi-Komponenten ist oft eine eigene Aufgabe. Versuche daher, es vorerst vor dem Import in Delphi durch ein Standard-Grid zu ersetzen, so dass du dir diese Baustelle für erste sparen kannst.

[Winni]

Hi!

NiceGrid gibt's hier:

https://github.com/nedich/NiceGrid

Zitat: "It is written from scratch, not descended from TStringGrid."

Also sollten eigentlich nicht allzuviel Schwierigkeiten auftauchen.

Winni
"

[mh18058]

Danke für Eure prompten Reaktionen. Das gibt Hoffnung!
@theo:

Aber ein neues Projekt (nicht dein Delphi Import) läuft?
Wie hast du importiert?
Über "Werkzeuge -> Delphi Umwandlung"?

Ja, ein neues Lazarus-Projekt läuft.
Ja, ich habe über "Werkzeuge -> Delphi-Umwandlung -> Delphi- in Lazarus-Projekt umwandeln" importiert.
Trotzdem waren da einige händische Nachbesserungen unter Uses der einzelnen Units notwendig.
Dabei habe ich mich von den Fehlermeldungen des Compilers leiten lassen.

@wp_xyz:
Das klingt interessant. Ich werde das morgen mal durchgehen und werde berichten ...
NiceGrid ist wie der Name schon sagt: 'nice'! https://github.com/nedich/NiceGrid (@Winni: Du warst schneller!)
Das würde ich am wenigsten als Ursache der Fehlermeldung ansehen, zumal es ohne Murren kompiliert wurde.
Aber, zugegeben, unter Lazarus habe ich noch keine Erfahrung damit.

Gruß
Martin

[wp_xyz]

Hab mir das NiceGrid angesehen. Es gibt ein paar Sachen, die man Nacharbeiten muss, aber das ist weniger Aufwand als es durch ein TStringGrid zu ersetzen. Trotzdem: portiere zuerst das NiceGrid und teste, ob alle von dir benutzten Features in Lazarus funktionieren, bevor du die Anwendung portierst, sonst schleichen sich Fehler ein, die du hinterher im "großen Werk" nur noch schwer findest.

Die Frage ist auch, ob dein Projekt nur unter Windows laufen soll, sondern auch auf anderen Plattformen. In letzterem Fall musst du die Units Windows und Messages aus der Uses-Liste des NiceGrid entfernen und duch LCLType and LCLIntf ersetzen. Und dann kanns aufwändiger werden, weil einige Window-Messages vorkommen, die du durch Lazarus-Messages ersetzen musst, und da steckt der Teufel oft im Detail.

[mh18058]

Hallo wp_xyz,
zuerst vielen Dank für Deine Hilfe. Das bringt mich weiter.

Ja, LCL war im Projekt eingetragen.
Offensichtlich erkennt Lazarus unter uses eingetragene Units nur, wenn sie ohne Namespace geschrieben sind.
Also z.B. nicht "Vcl.Forms", sondern nur "Forms".
Bei "Vcl.Forms" versucht Lazarus die Delphi-Unit und bei "Forms" das Pendant aus der LCL zu kompilieren. Das wird natürlich bei "Vcl.Forms" nix.
Also lautet meine erste vorsichtige Erkenntnis: Die Kompatibilität fängt schon im Delphi-Code an!

Mein Projekt soll erstmal nur unter Windows laufen. Insofern ist das mit NiceGrid wohl nicht so problematisch - hoffe ich.

Ich habe inzwischen auch Deine Hinweise umgesetzt und siehe da: Es kompiliert!
Allerdings wird das EXE nicht gefunden, siehe Anhang, und ist auch sonstwo nicht zu finden.
Weiterhin trägt die EXE den Namen der Mainunit und nicht den Namen des Projekts.
Außerdem vermisse ich die LPR-Datei. Eine LPI-Datei wird erzeugt. Ist das normal?
Möglicherweise hab´ ich aber durch die Rumprobiererei jetzt was ganz verkehrt gemacht.
Um sicher zu gehen hab´ ich dann nochmal ganz von vorn angefangen und Lazarus, mit Überschreiben der persönlichen Einstellungen, neu installiert.
Jetzt kämpfe ich mit der Kodierung von Chars und Strings ... ... offensichtlich werden Chars nur bis #127 und nicht bis #255 erkannt.
Wenn ich statt "ß" "#225" hinschreibe, ist die Fehlermeldung an dieser Stelle weg!
In den "Projekteinstellungen->Compilereinstellungen->Parsen->Ansi-Strings verwenden" anhaken bringt da auch nichts - logisch, geht ja auch um Chars.
Muß man da wirklich alles umschreiben, oder kann das LCL oder eine andere Kompatibilitäts-Unit leisten?

Bei Alledem merke ich, daß die Sache wohl nicht ganz so einfach ist, wie ich zunächst dachte.
Außerdem hab´ ich jetzt schon soviel rumprobiert ohne genau zu wissen was ich tue, daß ich langsam den Überblick verliere.
Also muß ich mich wohl erstmal genauer mit der LCL, bzw. den Lazarus-Kompatibiltäts-Units beschäftigen.

Hast Du einen Tip für ein gutes bewährtes Tutorial zu dem Thema?
Mit "gut und bewährt" meine ich: Wenn ich das durcharbeite, weiß ich Bescheid und kann die Portierung zielgerichtet umsetzen.
In viewtopic.php?t=10705 heißt es: "Eine Portierung ist immer heikel. "
Eigentlich wollte ich kein gesondertes Projekt draus machen, aber wenn´s hinterher funktioniert soll's mir Recht sein ...

Gruß
Martin

[theo]

Jetzt kämpfe ich mit der Kodierung von Chars und Strings ... ... offensichtlich werden Chars nur bis #127 und nicht bis #255 erkannt.
Wenn ich statt "ß" "#225" hinschreibe, ist die Fehlermeldung an dieser Stelle weg!
In den "Projekteinstellungen->Compilereinstellungen->Parsen->Ansi-Strings verwenden" anhaken bringt da auch nichts - logisch, geht ja auch um Chars.
Muß man da wirklich alles umschreiben, oder kann das LCL oder eine andere Kompatibilitäts-Unit leisten?

Lazarus verwendet Unicode UTF-8.
Deine Umlaute sind also keine Chars sondern Strings.
Deshalb meckert er. Da muss man umdenken.
Wie eine Lösung aussehen kann, hängt von der Verwendung ab.

[wp_xyz]

Eine wichtige Frage noch vorab: Soll das Projekt weiterhin von Delphi übersetzt werden können, oder willst du es nach der Portierung nur noch mit Lazarus weiterentwickeln?

[wp_xyz]

Im Unterschied zu vielen anderen mache ich die Delphi-Portierung nicht mit dem Delphi-Konverter in der IDE, sondern von Hand, denn da weiß ich genau, was passiert, welche Dateien schon konvertiert sind, wo sie stehen, wie ich Backups finde usw.

Als wichtigstes: Führe die Konvertierung nie am Original-Projekt durch, es besteht die Gefahr, dass du es in Delphi nicht mehr öffnen kannst, und du wirst immer wieder nachsehen müssen, wie es Projekt sich im unkonvertierten Zustand verhalten hat.

Grundannahme ist für mich in der Regel, dass ich das Projekt in Delphi nicht mehr weiterentwickeln werde, die Konvertierung ist eine Einbahnstraße und ich muss mich nicht darum kümmern, dass das Projekt noch unter Delphi les- und übersetzbar bleibt. Willst du da nicht so haben, musst du jede Änderung im Source-Code mit einem {$IFDEF FPC}...{$ELSE}...{$ENDIF} einschließen, wobei der FPC-Bereich den für Lazarus gültigen Code und der ELSE-Bereich den Original-Delphi-Code betrifft.

Ich spiele die Konvertierung gerade mit einem einfachen Delphi-Projekt durch, und schreibe mit, was ich mache.

• Die Projekt-Datei .dproj
  Diese entspricht der .lpi-Datei von Lazarus. Da diese Dateien völlig unterschiedliche Syntax haben, musst du hier nichts tun. Du kannst sie löschen, genauso wie die .dproj.local und die .identcache. Evenso kannst du die von Delphi angelegten .history-Ordner löschen.

• Die Projekt-Code-Datei .dpr
  • Diese entspricht der Lazarus-Datei mit der Endung .lpr. Benenne sie auf diese Endung um.
  • Öffne die Datei in einem Text-Editor (nicht mit der IDE).
  • Schreibe an den Anfang der "uses"-Zeile die Unit "interfaces" - das aktiviert das Widgetset-System von Lazarus; ohne dieses kannst du kein normales LCL-Programm erstellen.
  • Nicht 100% nötig, aber füge gleich nach dem "begin" die Zeile "RequireDerivedFormResource:=True;" ein.

• Die pas-Datei des Hauptformulars
  • Öffne die pas-Datei in einem externen Editor (nicht in der IDE).
  • Schaue dir die "uses" Zeilen an: Entferne ggfs die Namespace-Darstellung; das wird im Prinzip zwar unterstützt, nur müssten dann die LCL-Units für Lazarus anders heißen.
  • Schreibe an den Kopf der Unit die Zeile {$mode Delphi}. Das aktiviert den Delphi-Modus des Compilers und erspart dir später einige Fehlermeldungen wie z.B. wegen doppelter Bezeichner, oder bei Funktionspointern.
  • Unter "implementation" steht die Zeile "{$R *.dfm}". Lazarus kann zwar mit dfm-Dateien umgehen, aber du wirst den Inhalt der Datei ändern müssen, und damit kann sie von Delphi - falls du sie doch einmal in Delphi ansehen musst - nicht mehr gelesen werden. Daher gehe zum Benennungssystem von Lazarus über. Also: Ändere das zu "{$R *.lfm}"

• Die dfm-Datei des Hauptformulars
  • Benenne die Datei auf die Endung .lfm um.
  • Öffne die Datei in einem Text-Editor und entferne Zeilen, die offenkundig von Lazarus nicht erkannt werden. Das sind vor allem die "Explicit*"-Properties, die Lazarus nicht kennt. Auch "OldCreateOrder", "Ctrl3D", "ParentCtrl3D" muss raus.
  • Wenn dir der Editor keinen vernünftigen Text sondern binäre Zeichen anzeigt, dann handelt es sich um eine uralte binäre dfm-Datei, die Lazarus nicht lesen kann. Benenne sie zurück zur Original-Endung .dfm. Starte vorübergehend die Lazarus-IDE, gehe zu "Werkzeuge" > "Delphi-Umwandlung" > "DFM- und LFM-Datei umwandeln", lade diese binäre dfm-Datei und sie wird sofort als Text-Datei mit der Endung lfm gespeichert. Beende die IDE wieder und mache mit der erzeugten lfm-Datei so weiter wie oben beschrieben.

• Der Sprung ins Wasser
  • Nun öffne die .lpr-Datei mit Lazarus.
  • Da es noch keine .lpi-Datei mit den ganzen Projekt-Einstellungen gibt, fragt dich Lazarus, ob ein neues Projekt erzeugt werden soll: Ja.
  • Es erscheint eine Auswahl an Projekt-Schablonen. Nimm den obersten Eintrag "Anwendung". Eigentlich genauso, wie wenn du bei der normalen Arbeit mit der IDE ein neues LCL-Projekt anlegst.
  • Öffne den Projekt-Inspektor (der sollte sowieso immer offen sein): "Projekt" > "Projektinspektor"
  • In dem Baum unter "Dateien" steht bisher nur die lpr-Datei des Projekts. Wir müssen das Hauptformular zum Projekt hinzufügen: "Hinzufügen" > "Dateien aus dem Dateisystem hinzufügen" > die pas-Datei des Hauptformulars anklicken und öffnen. Sie muss nun in dem Baum unter "Dateien" erscheinen.
  • Jetzt unbedingt alles speichern, denn beim nächsten Schritt wird es spannend...
  • Im Projekt-Inspektor auf der pas-Datei des Hauptformulars doppelt klicken, um diese zu öffnen. Wenn du vorhin beim Bereinigen der dfm/lfm-Datei alle Problemfälle erwischt hast, wird das Formular komplett geladen. Wahrscheinlich tritt aber ein Ladefehler auf, weil irgendeine Eigenschaft nicht gültig ist. In diesem Fall erscheint eine Meldung mit dem Namen der Property. Schreibe dir die Komponenten und die Properties auf. Schließe die IDE OHNE ZU SPEICHERN! Öffne die dfm-Datei in einem externen Editor und lösche die Properties, die nicht geladen werden konnten. Es gibt auch eine Betriebsart in der IDE, in der man gefragt wird, alle unbekannten Properties zu löschen, aber ich weiß nie, wie ich da hinkomme... Und außerdem ist das riskant, denn es kann auch etwas gelöscht werden, was für das Projekt wesentlich ist, und du musst hinterher suchen, um das wieder zu finden.
  • Nun das Projekt wieder in die IDE laden. Evtl. musst du den Schritt von eben nochmals wiederholen. Wenn schließlich alles richtig ist, wird das Hauptformular ohne Fehlermeldung angezeigt. Drücke ggfs. die Taste F12, um zwischen Formular- und Editor-Ansicht hinunherzuschalten - das muss ohne Fehler funktionieren. Wenn ja, kannst du speichern.
  • Nun kommt der erste Versuch, das Projekt zu kompilieren. Es wird eine Menge an Fehlern hageln:
    • Fehlende Units: Wenn es sich dabei um Units deines Projektes handelt, ist das klar, denn diese hast du noch nicht konvertiert. Kommentiere sie fürs erste aus (und kennzeichne die Stelle, dass du sie später wiederfindest). Allerdings, wenn es sich um ganz zentrale Units (z.B. Deklarations-Units o.ä.) handelt, solltest du zunächst diese portieren, bevor du weitermachen kannst, sonst sammeln sich zu viele nachzuarbeitende Änderungen an.
    • Fehlende Funktionen/Prozeduren: Klar, wenn wir Units auskommentiert haben, fehlt auch der darin enthaltene Code. --> ebenfalls auskommentieren und kennzeichnen.
    • Manche Prozeduren sind in der LCL einfach nicht vorhanden. Mein Test-Projekt hier z.B. stolpert über die Methode TListView.Arrange, die es unter Lazarus nicht gibt. --> Mut zur Lücke: auskommentieren und kennzeichnen, und hoffen, dass es nicht so wesentlich ist. Darum kannst du dich später kümmern. Das wichtigste ist momentan, dass das Projekt kompiliert und in den Grundzügen läuft.
    • Wenn alles gut geht, hast du nun ein (verstümmeltes) Projekt, das übersetzt werden kann, und das die Grundzüge der Bedienung ermöglicht.
  • Im weiteren musst du das, was du mit dem Hauptformular gemacht hast, sukzessive mit den anderen Units/Formularen des Projekts wiederholen und Stück für Stück die Funktionalität wieder einbauen.
  Das alles ist relativ viel Arbeit. Aber auch mit dem automatischen Konverter geht es nicht viel schneller, denn die Hauptarbeit ist, die beim ersten Rutsch nicht portierten Teile wieder zum Laufen zu bekommen.
  
  Insgesamt würde ich sagen, das ist sowas wie die "Lazarus-Gesellenprüfung". Und wie jeder Lehrling macht man nicht am ersten Tag die Prüfung. Daher würde ich vorschlagen, vor der eigentlichen Konvertierung viele einfache Lazarus-Programm zu schreiben, so dass du Erfahrung gewinnst. Du könntest dir ja Teilaspekte des "großen" Programms, z.B. die Leseroutine für bestimmte Dateien, unabhängig vornehmen und daran üben.

[fliegermichl]

Ergänzend dazu würde ich zunächst alle eigenen Delphikomponenten, welche von Deiner Anwendung verwendet werden, in ein oder mehrere Lazaruspackages portieren und in kleinen Testprogrammen testen. Dann hagelt es auch nicht gleich ganz so viele Fehlermeldungen.

Ich plane ebenfalls eine Portierung:

Delphi Programm

massendach_compiled.png (10.97 KiB) 6111 mal betrachtet

[mh18058]

Hallo zusammen,
wow - danke für Eure reichhaltige Unterstützung! Das gibt mir die Zuversicht, daß ich das doch schaffen werde.

@theo

Lazarus verwendet Unicode UTF-8.
Deine Umlaute sind also keine Chars sondern Strings.
Deshalb meckert er. Da muss man umdenken.
Wie eine Lösung aussehen kann, hängt von der Verwendung ab.

Dann kann ich mir auch vorstellen, daß ein "ß" oder "§" nicht erkannt wird, weil die Zeichen nicht in der UTF8-Codepage vorhanden sind.
Für westeuropäische Codepage-1252 Nutzer ist das natürlich ziemlich bitter.
Auf Einzelschiksale kann offensichtlich keine Rücksicht genommen werden.
Oder kann man die Lazarus-IDE irgendwie dazu bringen, was anderes als UTF-8 zu kodieren?
Wenn nicht, dann bleibt tatsächlich nur ein Umprogrammieren übrig.

@wp_xyz
Danke für Deine ausführliche Anleitung! Das werde ich mal durchgehen und ausprobieren.
Es zeigt mir, daß die Sache tatsächlich nicht so einfach ist.
Daß Du die "Werkzeuge" garnicht benutzt, spricht allein schon Bände!
Ich habe auch den Eindruck, daß bei der automatischen Portierung Dinge passieren, die man nicht haben möchte und auch so einfach nicht mitbekommt.

Leider, nein zum Glück, gerät der Thread vom speziellen Thema "Kann WSImgList nicht finden" zum allgemeinen Thema "Projekt von Delphi nach Lazarus umwandeln" nun etwas off-topic.
Ich werde deshalb einen neuen Thread "Projekt von Delphi nach Lazarus umwandeln" aufmachen und dort auf diesen hier verweisen.
Also bitte alles weitere zum allgemeinen Thema "Projekt von Delphi nach Lazarus umwandeln" in viewtopic.php?f=55&t=14089
Das finden dann auch andere Interessierte, die nach Projektumwandlung suchen!

Gruß Martin

[PascalDragon]

@theo

Lazarus verwendet Unicode UTF-8.
Deine Umlaute sind also keine Chars sondern Strings.
Deshalb meckert er. Da muss man umdenken.
Wie eine Lösung aussehen kann, hängt von der Verwendung ab.

Dann kann ich mir auch vorstellen, daß ein "ß" oder "§" nicht erkannt wird, weil die Zeichen nicht in der UTF8-Codepage vorhanden sind.
Für westeuropäische Codepage-1252 Nutzer ist das natürlich ziemlich bitter.
Auf Einzelschiksale kann offensichtlich keine Rücksicht genommen werden.
Oder kann man die Lazarus-IDE irgendwie dazu bringen, was anderes als UTF-8 zu kodieren?
Wenn nicht, dann bleibt tatsächlich nur ein Umprogrammieren übrig.

Du hast wohl nicht richtig verstanden was UTF-8 ist: UTF-8 ist ein Multi Byte Encoding welches quasi alle bekannten Zeichen abdeckt. Der Punkt hierbei ist nur, dass Zeichen eben nicht nur mit einem einzigen Byte enkodiert werden, sondern eben mit 1 bis 4 je nach Zeichen. Alle Zeichen größer 127 ($7f) werden dabei mit mindestens zwei Byte kodiert. Das heißt, das die eben nicht in einen einzelnen Char passen, der nach wie vor 1-Byte ist.

[Winni]

Hi!

Unicode ist nur 30 Jahre alt.

Das war genug Zeit, Dich mal einzulesen.

Zum Nachholen:

https://wiki.freepascal.org/Unicode_Support_in_Lazarus

Winni

[wp_xyz]

Jetzt kämpfe ich mit der Kodierung von Chars und Strings ... ... offensichtlich werden Chars nur bis #127 und nicht bis #255 erkannt.
Wenn ich statt "ß" "#225" hinschreibe, ist die Fehlermeldung an dieser Stelle weg!
In den "Projekteinstellungen->Compilereinstellungen->Parsen->Ansi-Strings verwenden" anhaken bringt da auch nichts - logisch, geht ja auch um Chars.
Muß man da wirklich alles umschreiben, oder kann das LCL oder eine andere Kompatibilitäts-Unit leisten?

Wie die Vorredner schon sagten, verwendet Lazarus die UTF-8-Kodierung. Alle ASCII-Zeichen (mit Wert < 128) bleiben unverändert (1 Byte), aber alle anderen Zeichen werden aus zwei bis vier Bytes zusammengesetzt. Unter "Bearbeiten" > "Aus Zeichentabelle einfügen" findest du eine Aufstellung aller UTF8-"Zeichen" (Lasche "Unicode"). Das Zeichen 'ß' besteht nun aus den beiden Bytes #$C3 und #$9F.

In den aller-aller-meisten Fällen spielt dieser Unterschied in der Praxis keine Rolle. Wenn du eine Unit erzeugst, so werden alle Zeichen, die du dort eingibst, als UTF-8 abgelegt, und wenn du einen String, der ä,ö,ü,ß enthält einen Lazarus-Control zuweist, wird er automatisch korrekt angezeigt. Nur wenn du Text-Dateien einliest, oder unter Windows direkte Betriebssystemaufrufe macht, muss man vorsichtig sein.

Aufpassen muss man auch, wenn man die "wahre Länge" eines Strings benötigt, worunter ich die Anzahl der Zeichen verstehen möchte. Dafür nimm die Function UTF8Length(ein_string) aus der Unit LazUTF8. Die Standard-Funktion Length() übergibt immer die Anzahl der Bytes. (Length('Straße')=7, aber UTF8Length('Straße') = 6).

Auch um einen Teilstring aus einem String zu holen gibt es einen Spezialfunktion, UTF8Copy: UTF8Copy('Straße', 6, 1) = 'e'. Das Standard-copy würde #$9F zurückgeben, das ist das zweite Byte des 'ß'.

Usw, usf. Schaue dir die Unit LazUTF8 näher an, oder auch LConvEncoding (Umwandeln von String-Kodierungen). Es gibt auch einige wiki-Artikel darüber, z.B. https://wiki.freepascal.org/LCL_Unicode_Support/de.

Generell aber nochmal: Die Stringbehandlung ist sehr transparent (z.B. AnsiUppercase('Würde') = 'WÜRDE') , und die speziellen UTF8-Funktionen braucht man erstaunlich selten.