af0815 hat geschrieben:
Jetzt fehlt eigentlich noch das Gegenstück
Meinst du zum speichern? Weiss nicht. Das scheint mir etwas weniger eindeutig. Mit UTF-8 gehen eigentlich keine Infos verloren.
Wenn man z.B. unter Win mit Systemdateien arbeitet, reicht eigentlich UT8ToSys.
af0815 hat geschrieben:
Wa mir allgemein fehlt, ist Information was für Routinen es bereits für das Handling gibt. Zumindest leicht auffindbare.
Ja, chaotisch das Ganze.
af0815 hat geschrieben:
Könnte es sein das der Uniloader nicht in die LConvEncoding hineinpassen würde ?
af0815 hat geschrieben:
Könnte es sein das der Uniloader nicht in die LConvEncoding hineinpassen würde ?
Was meinst du damit?
Das 'nicht' sollte positiv besetzt sein (deutsche Sprache, schwere Sprache)- Ich schreib den Satz nochmals - Könnte es sein das der Uniloader in die LConvEncoding hineinpassen würde ?
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).
Ich bin mir nicht sicher. Das hat auch mit dem erwähnten Chaos zu tun.
Vieles was man nun in der LCL macht, um gewisse Dinge "zum laufen" zu bringen, müssten eigentlich in die FCL oder gar in den Compiler.
Da gibt es jetzt schon Doppelspurigkeiten.
Die D2009 Kompatibilität steht evtl. auch noch ins Haus. Hier bräuchte es mal eine Roadmap vom FPC Team.
Vielleicht besser erstmal mit "externem Flickwerk" (wie dem Uniloader) zu arbeiten statt die LCL noch weiter aufzublasen mit Codes die vllt. bald überflüssig werden.
Das ist imho ein Schwachpunkt von OpenSource Teamarbeit, da ist einfach kein Masterplan erkennbar. Mit der Grafik ist es ähnlich.