Theo's UTF8Tools können in Laz 5.99 nicht mehr kompiliert werden

[wp_xyz]

Nach dem Taggen der Lazarus-Version 5.0 wurde eine Vielzahl von Codestellen entfernt, die als "deprecated" markiert waren. (*) Seitdem können theo's UTF8Tools aus OPM nicht mehr mit der Trunk-IDE (v5.99 jetzt) kompiliert werden. Schuld ist die verwendete Anweisung UTF8CharacterToUnicode, die in UTF8CodepointToUnicode umbenannt werden muss - dann geht's wieder.

theo, wenn du das in der Version auf deiner Seite korrigierst, könnte ich den OPM entsprechend aktualisieren.

----------
(*)
Falls bei jemandem Code plötzlich nicht mehr funktioniert, kann das die Ursache sein. Das häufigste Problem ist wahrscheinlich, dass der Befehl DebugLn nicht mehr gefunden wird. Der war früher in Unit LCLProcs und ist nun schon seit längerem in LazLoggerBase.

[theo]

theo, wenn du das in der Version auf deiner Seite korrigierst, könnte ich den OPM entsprechend aktualisieren.

Danke für den Hinweis und für das Aktualisieren des OPM.
Die aktualisierte Version befindet sich am gleichen Ort.

[wp_xyz]

Danke, im OPM aktualisiert.

Ich habe dann allerdings versucht, die beiden im Package enthaltenen Demo-Programme zu kompilieren, und erhalte den seltsamen Fehler "win32int.pp(11,65) Error: Can't find unit Win32Int used by Interfaces" (bin auf Windows). Bin ratlos, kann keinen Fehler weder in deinem Package noch in den Demo-Programmen finden.

[theo]

Danke!
Ich bin selber nicht mehr auf Windows.
Das Ganze ist natürlich schon etwas alt, aber auf Linux funktionieren die Beispiele.
Kannst du mal in die ".lpr schauen, ob da vielleicht etwas weg muss für Windows?

z.B.

Code: Alles auswählen

{$IFDEF WINDOWS}{$R project1.rc}{$ENDIF}   

Ich hatte mir das gar nicht mehr angesehen, da es auf Linux keine Probleme gab.

[wp_xyz]

Ja, da war ich schon:

Code: Alles auswählen

program project1;

{$mode objfpc}{$H+}

uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Interfaces, // this includes the LCL widgetset
  Forms
  { you can add units after this }, Unit1; //, LResources, utf8tools;

//{$IFDEF WINDOWS}{$R project1.rc}{$ENDIF}
{$R *.res}

begin
//  {$I project1.lrs}
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.  

Kein Erfolg...

Noch mysteriöser: Ich habe eine neues leeres Projekt erstellt, und nur utf8tools zu den Requirements hinzugefügt --> derselbe Fehler.

Linux getestet - du hast recht, da geht alles. Habe die Widgetset-Kompatibilitätsliste in der Packagebeschreibung um gtk3, qt5 und qt6 ergänzt.

[fliegermichl]

Das liegt an der unit character.pas. Die gibt es auch nochmal im rtl Source.
Wenn man die Unit im Package umbenennt, compiliert es.

[wp_xyz]

Ah, gut beobachtet! theo, kannst du das umbenennen? Trotzdem hat man jetzt die umgekehrte Frage: Warum ging es unter Linux, wo es doch auch die RTL-Unit character gibt?

[sstvmaster]

Eventuell noch Suchreihenfolge der Units und/oder gross/klein Schreibweise?

[theo]

Trotzdem hat man jetzt die umgekehrte Frage: Warum ging es unter Linux, wo es doch auch die RTL-Unit character gibt?

Der Unterschied ist wohl, dass die RTL Unit ein grosses "C" verwendet und meine ein Kleines (Character - character).
Windows macht da wohl im Ggs. zu Linux keinen Unterschied.
Aber wieso ging es dann bisher auf Windows? Oder ist das schon länger so?
Ich habe jetzt ja nur UTF8CharacterToUnicode geändert und gar nichts an den Dateinamen oder Unit-Abhängigkeiten?
Meine "character.pas" war vor der RTL Version da und ich habe nie von einem solchen Problem gehört.

[theo]

So, hab's noch einmal geändert und hochgeladen
Geht es jetzt auf Win?