[fpc-devel] TRegistry and Unicode

[Bart]

On Sat, Mar 16, 2019 at 4:36 PM Michael Van Canneyt
<michael at freepascal.org> wrote:

> > I can declare the type there as well, but for the compiler these will
> > be 2 different types.
>
> In Delphi yes, but normally not in FPC. If the base type is the same, 2
> array definitions will be assignment-compatible.

Thanks for pointing that out.

I implemented it that way now.

I attached registry.unicode.part5.diff for review to
https://bugs.freepascal.org/view.php?id=35213 .

===
All public and protected methods now default to UnicodeString.
Overloaded versions with String parameters use implicit conversion
to/from UnicodeString.

Introduced new methods that read/write TUnicodeStringArray parameters.
All methods using TStrings now uses the methods using TUnicodeStringArray.
(In XMLReg unit I did not remove the existing implementation using
TStrings, because AFAIK this unit can be used stand alone, and it
would therefore not be backwards compatible.)

ReadStringList/WriteStringList have optional parameter to control if
the Strings are encodes as UTF8.
GetKeyNames and GetValueNames with TStrings parameter encode the
resulting strings as UTF8.
(I did not include an optional paramter as for Read/WriteStringList,
because then the signature is no longer Delphi compatible.
If so desired this paramter can be added. It's a trivial change.)

As discussed: in XMLReg WriteStringList now writes UnicodeStrings to
the reg.xml file, which the previous implementation (trunk only) did
not. It was judged to be acceptable.

TXMLRegistry internally now uses UnicodeString everywhere (except for
the Filename property and HexToBuf/BufToHex, where it seemed to make
no sense to convert this to UnicodeString).
There are still warnigs about implicit UnicodeString to String
conversions, but they are in codepaths that are not used by TRegistry.

I changed some existing $ifdefs to make it easier to use and test the
XML implementation under Windows.
(Simplye defining XMLREG would not compile under Windows)

I added some conditional compilation to XMLReg unit for the same reason.

When reading Reg_Multi_SZ data, trailing zero's are deleted regardless
of value of StringSizeIncludesNull, because (by Windows definition)
this data cannot contain empty strings.

In the XMLReg implementations I did some Explicit UnicodeString to
String conversions in places where the string in question can only
contain '0'..'9','A'..'Z'.
It suppresses a warning and it is safe by definition in those places.

I had to fix TXmlRegistry.HexToBuf.
The fact that it worked before was by pure luck.
=====

It builds on Win32, Win64 and WinCe.
I can now read/write Unicode keys, names in both XMLREG and Windows
implementation.
I attached a reg.xml with Unicode Keys and Values as an example.
I tested reading and writing all the default types (string,
multistring, integer, int64, float, date, time, datetime).

There are still several debug writeln statements (all commented out)
in the source code, they shall be removed at some point in time of
course.

The patch file is 2063 lines....

I would appreciate a review and feedback.
Especially function TRegistry.GetKeyNames: TUnicodeStringArray; and
function TRegistry.GetValueNames: TUnicodeStringArray; in the Windows
implementation: where I assign u:=lpName (u=UnicodeString,
lpName=LPWSTR), maybe a UniqueString is needed??
It does not crash here, but that may also be pure luck.
I propose to continu the discussion in the bugtracker then, unless
there are fundamental objections agains my proposed patch.

--
Bart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reg.xml
Type: text/xml
Size: 1055 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190317/78fb8c4e/attachment.xml>