Martin Schreiber wrote / napísal(a):
On Wednesday, 12. January 2011 09.45:47 LacaK wrote:
So where is error ?
1. Is it wrong expectation by LCL, that TField.Text is always UTF8 string
-or-
2. Is it wrong in implementation of TSQLConnectors, which write data
into record buffer (of TStringField) and do not convert them always into
UTF-8 ?
(if data should be always in UTF-8 then it will be good redefine
TField.Text property like "property Text: UTF8String" to be clear, that
we always work with UTF-8 strings)
-or
3. I missed something ? ;-)
MSEgui sqldb version converts to UTF-16 from/to system encoding or utf-8
(selectable by option properties) and uses FPC 16bit UnicodeString to store
string field values in the dataset, the tmsestringfield returns UnicodeString
values. So one can either use utf-8 encoded databaseconnections or
connections with the current system encoding.
MSEgui uses 16 bit UnicodeString everywhere, the conversion from/to system
encoding is done transparently by the FPC unicode/widestring-manager if
necessary.
This is a solution which works now, no additional complicated and possibly
less performant codepage and encoding aware stringtype necessary...
Yes, sounds logicaly to me.
Then you propose same way for TStringField ? (internaly store as
UnicodeString UTF-16 and also TStringField.Text should return
UnicodeString instead of String ? ... what will happens in LCL, when
visual component will read UTF-16 string, will they be translated into
UTF-8 automagicaly?)
-Laco.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
