[gelöst] - Insert geht nicht mehr...

[mse]

Außerdem sagen die Lazarus-Leute ja dass sie mit gutem Grund die API mit UTF8 machen, weil GTK anscheinend so arbeitet und dann in der LCL nicht so viel konvertiert werden muss.

Windows und Qt arbeiten mit utf-16, X11 hat ebenfalls eine utf-16 Schnittstelle, Mac kenne ich nicht. utf-8 wurde soviel ich weiss auch deshalb gewählt, weil es einen fliessenden Übergang erlaubte. Bei MSEgui ist es so, dass alle strings als msestring angegeben werden. In msestrings.pas ist msestring = widestring definiert. Beim erscheinen des neuen, auf allen Plattformen Referenz gezählten FPC UnicodeString kann dann schmerzlos auf msestring = UnicodeString gewechselt werden. Übrigens wäre der fliessende Übergang auch mit widestrings möglich gewesen, da FPC mittels des widestring Managers die automatische Konvertierung ansistring widestring übernommen hätte.

Das ist für Delphi-Umsteiger aber anscheinend nicht einfach....
(für mich ganz unmöglich, da - wenn überhaupt - die portierte Software im Endeffekt auf Delphi kompilierbar bleiben muss)

MSEgui kann, mit Ausnahme der DB-Komponent, mit Delphi 7 kompiliert werden.

[mse]

UTF8 ist natürlich keine Codepage, aber wenn der Stringtyp sich seine Codierung merken kann, ist das eine sinnvolle Erweiterung.

Diesen String Typen sollte man aus performance und Speicherplatzrgründen nur verwenden, wenn es durch unbekannte Codierung notwendig ist. Ansonsten sind ansistring für das 8Bit Betriebssysteminterface und widestring für den Rest besser geeignet. Wenn das GUI Framework mit widestrings arbeitet, werden utf-8 strings nur noch selten benötigt.

[theo]

Bei MSEgui ist es so, dass alle strings als msestring angegeben werden. In msestrings.pas ist msestring = widestring definiert.

Wenn das GUI Framework mit widestrings arbeitet, werden utf-8 strings nur noch selten benötigt.

@mse: Darf ich dich darauf hinweisen, dass wir uns im deutschen Lazarusforum in "Lazarus - Bugs" befinden.
Du hast deine eigene Mailinglist und eine Abteilung "MSEide und MSEgui" auf diesem Host.
Wenn wir Informationen zu MSEgui benötigen, werden wir sie dort suchen.
Ich glaube es ist nicht notwendig, dass du zu jeder Lazarus-bezogenen Frage MSEgui erwähnst.

[mschnell]

zweiteres wenn S Ansistring ist: UTF-8. Was sonst?

Wenn di codierung der aktuellen (oder sonst einer) Codepage es hergibt, reicht doch eine ein-Byte-pro-Char Kodierung,

Naja, "65001 is the code page number for UTF-8 on the Windows platform"

Und das heißt dann "ANSI-code-page" ?!?!?!? (Dass man einen ANSIString dazu vergewaltigen kann die Sequenz von subcodes zu speichern steht natürlich ausser Frage, man sollte es aber dann doch ehrlicherweise UTF8String nennen).

-Michael

[mschnell]

Wenn das GUI Framework mit widestrings arbeitet, werden utf-8 strings nur noch selten benötigt.

Erzähl' das 'mal den Lazarus-Machen .
-Michael

[mschnell]

MSEgui kann, mit Ausnahme der DB-Komponent, mit Delphi 7 kompiliert werden.

Ein paar konditionale Kompilierungen würden ja auch nicht sehr weh tun, aber soweit ich das bisher mitbekommen habe, ist es doch kaum möglich Delphi Forms auf MSE zu portieren. Das geht bei Lazarus einigermaßen.

-Michael

[mschnell]

@mse: ... Ich glaube es ist nicht notwendig, dass du zu jeder Lazarus-bezogenen Frage MSEgui erwähnst.

Ich war es, der in diesem Thread mit MSEGUI angefangen hat...
-Michael

[mse]

Ich glaube es ist nicht notwendig, dass du zu jeder Lazarus-bezogenen Frage MSEgui erwähnst.

Nun, die Internas von MSEgui sind relativ unbekannt und könnten als Anregung für Lazarus Benutzer schon von Interesse sein. Beispielsweise könnten die Lazarus Nutzer schon jetzt statt UTF8String oder ansistring oder string die Bezeichnung Lazstring verwenden damit die eventuelle Umstellung auf den evenuell kommenden perfekten String weniger Arbeit macht.

Martin

[theo]

auf den evenuell kommenden perfekten String weniger Arbeit macht.

Und wie sieht der aus, der "perfekte String"?

[mse]

Und wie sieht der aus, der "perfekte String"?

Selbstverständlich gibt's den perfekten String nicht. Warum ich utf-8 und Multiencoding Strings als interne Stringdarstellung für ein GUI Framework nicht als ideal erachte, habe ich hier, auf fpc-pascal und fpc-devel schon genügend dargelegt.

[theo]

Selbstverständlich gibt's den perfekten String nicht. Warum ich utf-8 und Multiencoding Strings als interne Stringdarstellung für ein GUI Framework nicht als ideal erachte, habe ich hier, auf fpc-pascal und fpc-devel schon genügend dargelegt.

Und welche Probleme löst denn der UTF-16 String gegenüber dem UTF-8 String?
In beiden Fällen ist doch das direkte mapping "Char:=Unicode CodePoint" nicht möglich. Das wäre erst mit UCS4Char möglich.
Man kann vielleicht für eine konkrete Anwendung die CodePoints über $FFFF ignoriereren, aber Copy, Insert, Delete, Uppercase etc. darf das für UTF-16 genausowenig wie für UTF-8 > dez 127.
Ich verstehe das Argument immer noch nicht wirklich.

[pluto]

scheint ja ein recht komplexes Thema zu sein. Evlt. währe es hilfreich darüber mal ein Tutorial zu verfassen.

Heißt das denn jetzt einfach: Wenn ich überall im Programm Widestring verwende ist es UTF8 Fähig ? und heißt das dann auch das es für komplett andere Sprach System geeignet ist z.b. Russisches oder sprachen mit anderen Buchstaben als wir sie kennen ?
Sind die meisten Funktionen und Proceduren dann auch Automatisch UTF8 Fähig ? z.b. bei Insert weiß ich es aber bei copy und Pos und delete ist das da auch so ?

[theo]

scheint ja ein recht komplexes Thema zu sein.

Da hast du recht

Heißt das denn jetzt einfach: Wenn ich überall im Programm Widestring verwende ist es UTF8 Fähig ? und heißt das dann auch das es für komplett andere Sprach System geeignet ist z.b. Russisches oder sprachen mit anderen Buchstaben als wir sie kennen ?
Sind die meisten Funktionen und Proceduren dann auch Automatisch UTF8 Fähig ? z.b. bei Insert weiß ich es aber bei copy und Pos und delete ist das da auch so ?

Es wurde hier in den letzten Tagen viel darüber geschrieben. Lies das doch erstmal durch, bevor wir alles nochmal wiederkäuen.

[mse]

Man kann vielleicht für eine konkrete Anwendung die CodePoints über $FFFF ignoriereren, aber Copy, Insert, Delete, Uppercase etc. darf das für UTF-16 genausowenig wie für UTF-8 > dez 127.

Uppercase() hat einen 8Bit Parameter, berücksichtigt lediglich 'a' bis 'z' und funktioniert für utf-8. Für widestring sollte es nicht verwendet werden, da eine zusätzliche Wandlung utf-16 -> 8bit notwendig wird. Es gibt auch Umgebungen, wo eine entsprechende ASCII uppercase version auch für widestrings zur Verfügung steht. wideuppercase() benutzt unter Windows eine utf-16 Systemroutine. Upper und Lowercase hat ausserhalb der BMP sowieso keine Bedeutung. Für utf-8 muss zuerst in utf-16 gewandelt weden, bevor die Windows Systemroutine aufgerufen werden kann.
Pos() mit strings funktioniert sowohl für utf-8 als auch für utf-16. In Europa wird man mit dem Suchen einzelner Zeichen mit utf-8 Probleme bekommen, mit utf-16 nicht.
Copy(), Insert() und Delete() funktionieren für utf-8 und utf-16, solange keine utf-8 Sequenzen respektive surrogate pairs getrennt werden. Falls man den index und die Längen mittels pos() findet, ist die Sache sicher, sonst wird es in Europa mit utf-16 funktionieren, mit utf-8 nicht.

[mschnell]

Evlt. währe es hilfreich darüber mal ein Tutorial zu verfassen.

Leider ist noch keine Tutorien-Würdige Methodik zur Verwendung von Unicode in Lazarus gefunden worden, weil die Voraussetzung erinfach zu schlecht sind .

-Michael