On Mon, 03 Nov 2008, Szak�ts Viktor wrote: Hi Viktor,
> And here could come the advantage of being internally Unicode, > since in this case the CP doesn't need to be added next to > each string. And this is probably we should rather do, instead > of introducing CP information for each string. And just catch > the I/O points where such CP information is needed to know > how to interpret non-Unicode strings. But how do you plan plan to resolve the problem with binary data? What to do with FREAD()/FWRITE() buffers? Using internally UNICODE for all string items resolves one problem but creates many new ones for code which have to operate on binary data. > Anyhow the RDD codepage support seems also quite broken then, > and the final word is that currently Harbour doesn't really > support CPs, besides one per app selected for the RDDs plus > all the app string functions (comparison, UPPER()/LOWER()), > and there is a grade of support to convert strings to another > CP for GT output. Period. Harbour support some limited automatic CP conversions in some input/output operations and allows to dynamically switch collation rules and ALPHAs, UPPERs, LOWER sets. Nothing more nothing less. The translation in current native RDDs is in practice limited to single country CPs. It allows to resolve problems introduced by many historical CPs and I guess it was Alexander intention when he was adding it. I'm finding it usable in my country where I have to leave with ISO-8859-2, CP852, CP1250, Mazovia and few other CPs much more seldom used. > This - even now - could cause all sort of problems, if a > 3rd party lib tries to fiddle with hb_setcodepage(). Yes of course. But the same you can say about most of other SETs. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
