| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0036663 | FPC | FCL | public | 2020-02-06 07:18 | 2020-02-07 18:48 |
| Reporter | Wallaby | Assigned To | Michael Van Canneyt | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | Win32 | OS | Windows | OS Version | 10.0 |
| Product Version | 3.3.1 | Product Build | 3.3.1-r44120 [2020/02/06] x86_64 | ||
| Target Version | Fixed in Version | 3.3.1 | |||
| Summary | 0036663: Broken TRegistryIniFile | ||||
| Description | The following code works incorrectly in trunk and fixes_3.2: {$MODE DELPHI} program test; uses Registry; const RegPath = 'Software\Company Name\Product Name'; begin {Write} with TRegistryIniFile.Create(RegPath) do try WriteString('Test', 'Key', 'Value'); finally Free; end; {Read} with TRegistryIniFile.Create(RegPath) do try WriteLn(ReadString('Test', 'Key', 'Duh!')); finally Free; end; end. Instead of creating: HKEY_CURRENT_USER\Software\Company Name\Product Name It creates HKEY_CURRENT_USER\Software\Company Name\Product Name\Software\Company Name\Product Name\Test On top of that no value is written. The above code will print "Duh!" rather than "Value". As far as I can tell it's related to converting TRegistry to Unicode. It would be great to have this fixed before 3.2 release as this will break many programs. | ||||
| Steps To Reproduce | Compile and execute the attached program. Open regedit.exe, navigate to HKEY_CURRENT_USER\Software\Company Name and expand it all the way down. Note that the path is wrong and no value was written. | ||||
| Tags | Registry | ||||
| Fixed in Revision | 44127 | ||||
| FPCOldBugId | |||||
| FPCTarget | 3.2.0 | ||||
| Attached Files |
| ||||
|
|
test.pas (411 bytes)
reg-err-path.png (30,778 bytes) |
|
|
> As far as I can tell it's related to converting TRegistry to Unicode. That doesn't seem very likely. TRegIniFile was already broken long before I rewrote TRegistry to be fully unicode. See e.g 0035022 (TRegIniFile writes to the wrong key) Please apply registry.currentpath.diff and then reginifile.opensection.diff in that report and see if that fixes the issue. > as this will break many programs. TRegIniFile was introduced to make porting applications from using INI files to use the Windows registry easy, I believe when Win95 came out in the era of D2 (?). If you insist on using the registry, then moving to using TRegistry was the way to go (you've had > 20 years to adapt your code). |
|
|
TRegistryIniFile simply encapsulates a TRegIniFile b.t.w. Hence my reference to TRegIniFile. |
|
|
> It would be great to have this fixed before 3.2 release It's a regression, so it has to be fixed before 3.2 Probably I broke it, so I'll try to fix it. > The above code will print "Duh!" rather than "Value" ReadString tries to read from the correct path (WriteString wrote to the wrong path), so it obviouslly cannot find the correct result. |
|
|
Indeed it was my fault. I messed up handling of Key in the Windows implementation of sysCreateKey in r41784. Uploaded patch.
registry.syscreatekey.diff (728 bytes) |
|
|
@Wallaby: please test with attached patch. I asked on the devel ML to have it applied ASAP. |
|
|
Applied patch from Bart, thank you very much. |
