ab wrote:
The UTF-8 encoding will be used only at lower level, i.e. at ZDBC level.
All the conversions will take place when calling the ZDBC interfaces, automatically by the ZEOS units.
Please don't forget that Lazarus' LCL uses UTF8 internally, not UCS2 like Delphi's VCL.
Zeos is very important for Lazarus users, so please take care not to break this functionality. Please keep in mind that LCL controls use UTF8 and that no automatic conversion when communicating with ZDBC layer should take place in LCL.
ab wrote:At the VCL component level (e.g. TDataSet or TQuery Zeos versions), the type for strings will be the plain Delphi string type.
For instance, SQL.Text will expect string type, i.e. UCS2 since Delphi 2009.
The UTF-8 encoding will be used only at lower level, i.e. at ZDBC level.
All the conversions will take place when calling the ZDBC interfaces, automatically by the ZEOS units.
For high-level users only playing with VCL components, you won't see any difference. You'll use Delphi string values, just as usual.
I would appreciate if this (more simple?) question is answered:
With new UNICODE features implemented in zeoslib, can end users see UCS2 string values correctly rendered by VCL DB components like TDBEdit and TDBGrid, and save the new/modified UCS2 string values to databases that accepts UTF8?
cnliou wrote:With new UNICODE features implemented in zeoslib, can end users see UCS2 string values correctly rendered by VCL DB components like TDBEdit and TDBGrid, and save the new/modified UCS2 string values to databases that accepts UTF8?
Answer is Yes (at least it's the main intent of my Zeos fork).
And about LCL, it's very easy to let RawUTF8 be an UTF-8 string. With function inlining, it will be a direct assignment/variable bypass, with no conversion.
How's the status of this operation? Next week I might have more time to spend for helping out a little. Mainly because of the loads of snow we got here and because of christmas holiday.
