Da hat wohl jemand Mist gebaut und nicht bedacht, dass diese Streams auch von anderen benutzt werden können. (wie z.B. von dir oder uns ... zum Glück bin ich noch nicht so weit, mit der Umstellung auf 10.4)
Auch bei "älteren" DFMs, welche noch binär gespeichert sind oder noch nicht umgestellt wurden (nicht als Text-
DFM), wird es somit Probleme geben.
In der EXE-Ressource sind die zwar binär hinterlegt, aber da dort mit der selben TReader/TWriter-Verion gelesen wird, wie der Compiler es abspeicherte, ist das wohl noch niemandem ausgefallen.
Da kannst du nur an den Hersteller wenden, dass die das gefälligst beheben.
Bisher, und das muß eigentlich auch so bleiben, war vaString ein ShortString mit
ANSI.
Per se ist es gut das
ANSI aus DFMs (diesen Streams) zu verbannen, denn in einem deutschen Windows kompiliert und in einem anderem Windows gestartet, z.B. in französisch/englisch/russisch/chinesisch/..., da hatte man schon immer Spaß.
Aber das darf nicht das Lesen "alter" Streams beeinflussen.
Beim
neu Speichern darf in vaString einfach nur ausschließlich
ASCII [#0..#127] rein und der Rest muß in vaUTF8String. Und vaString ist und bleibt
ANSI, beim Lesen.
Wobei ich mir fast sicher bin, dass ich unsere Streams nur als Text speichere und somit hoffentlich vielleicht keine Probleme bekomme,
falls ich auch beim FastReport da nichts übersehn hab.