TRegistry.MoveKey does not move MultiSZ values correctly?

[Nigel Thomas 28]

Hi All,

 

Am I right in concluding that TRegistry.MoveKey fails to move REG_MULTI_SZ values correctly?

 

In tests using D2007 and D10.4.2 (the code doesn't appear to have changed across those versions) such a move results in the creation of a value with REG_NONE and the strings from a MultiSZ value copied as raw binary data.

 

I get why; DataTypeToRegData returns a TRegDataType and that type doesn't have a MultiSZ value.

 

Given that RegQueryValueEx and RegSetValueEx do know about REG_MULTI_SZ, I'm guessing that MoveKey could be fixed to work correctly with MultiSZ registry values. I would however have thought that someone might have picked up this issue a long time ago, so I'm wondering if it's just me being dense.

 

And if it's not me being dense, how to I go about fixing it given that I can't modify TRegistry?

[Sherlock 627]

8 hours ago, Nigel Thomas said:

And if it's not me being dense, how to I go about fixing it given that I can't modify TRegistry?

That is easy and the solution comes in two parts: 1. Create an Issue on the quality portal. And b) Copy the source into your projects folder or any other folder where you would keep reusable units. Then fix the issue and add said folder to your search path to use the modified unit in your project.

[Attila Kovacs 617]

Swap the orders, first "b)" then "1."

That you can:

 I. Be sure you can fix something, so it's definitely broken.

 II. You can make a fix proposal (They will most probably fix it in an other way but it helps them to understand a problem and it's also represents the "expected" result.

     Such reports are processed faster.

 

[Remy Lebeau 1257]

23 hours ago, Nigel Thomas said:

Am I right in concluding that TRegistry.MoveKey fails to move REG_MULTI_SZ values correctly?

Yes.  TRegistry has never supported REG_MULTI_SZ in any capacity.  No read/write methods, no copy/move semantics, nothing.  I don't know why, it's been around like forever.  Same with REG_QWORD, too.

Quote

I get why; DataTypeToRegData returns a TRegDataType and that type doesn't have a MultiSZ value.

Correct.  Which is weird that they waste effort turning the reported data type id into an enum just to turn it back into a data type id immediately afterwards.  If they just used the original data type id as-is, there would be no problem.

Quote

Given that RegQueryValueEx and RegSetValueEx do know about REG_MULTI_SZ, I'm guessing that MoveKey could be fixed to work correctly with MultiSZ registry values.

Yes, it could be fixed.

Quote

I would however have thought that someone might have picked up this issue a long time ago, so I'm wondering if it's just me being dense.

It is not just you. https://quality.embarcadero.com/browse/RSP-15275

Quote

how to I go about fixing it given that I can't modify TRegistry?

Yes, you can, actually.  Until Embarcadero fixes it properly, you could simply modify the implementation (not the interface) of the System.Win.Registry.pas file (ie, to make TRegistry.MoveKey() not use TRegistry.GetData() since it doesn't report the types correctly), and then add that modified unit to your projects.  The compiler will then use your modified unit instead of the original.

 

Note that this only works if you are NOT compiling with Runtime Packages enabled, though.

Edited October 1, 2022 by Remy Lebeau

[Nigel Thomas 28]

Let's see if they at least fix REG_MULTI_SZ: RSP-39581