Recent

Author Topic: Reading Registry key by name fails for specific name [SOLVED]  (Read 6841 times)

idog

  • Full Member
  • ***
  • Posts: 121
    • www.idogendel.com (Hebrew)
Reading Registry key by name fails for specific name [SOLVED]
« on: September 23, 2017, 08:33:30 pm »
Hi all, haven't been here for a while :-)

I have a program that reads the available COM ports from the Windows 10 registry (at HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM\ ). It uses the TRegistry class with the usual methods (OpenKeyReadOnly, GetValueNames, ReadString etc.)

The program worked well for a long time, but at some point something changed (external to the program). I traced the issue to an Arduino clone with the CH340G USB-to-UART chip. The screenshot shows actual data from the registry. You can see two COM ports there: COM21 (key name '\Device\USBSER001') and COM3 ('\Device\Serial').

In my program, both keys are found, and the string 'COM21' is read correctly; it's associated with another Arduino with a different chip. However, for the other key I get an empty string instead of 'COM3'.

Windows itself, the Arduino IDE and a test program I wrote in Delphi all see and handle this 'COM3' string with no problem, but Lazarus can't read it.

I suspect that it's an encoding issue because the raw key name in Lazarus actually appears as '\Device\Serial?', and the Delphi debug watch said it's '\Device\Serial'#$0082 . So far I couldn't find a character to remove or add that will resolve this issue.

If you're still with me :) - any idea on how to tackle this matter?

Thanks,
« Last Edit: September 26, 2017, 12:38:29 pm by idog »

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Change your string type to AnsiString or UnicodeString. This looks like UTF16. FPC can handle it (Lazarus too,but not without manual intervention) so use one of the FPC supported string types when moving Delphi code. If it is a recent Delphi, use either {$mode delphiunicode}or better change the string declarations from string to unicodestring.

There is one person who will try to explain otherwise, don't believe him, do what I say. Then it works.
« Last Edit: September 23, 2017, 08:50:48 pm by Thaddy »
Specialize a type, not a var.

idog

  • Full Member
  • ***
  • Posts: 121
    • www.idogendel.com (Hebrew)
Change your string type to AnsiString or UnicodeString. This looks like UTF16. FPC can handle it (Lazarus too,but not without manual intervention) so use one of the FPC supported string types when moving Delphi code. If it is a recent Delphi, use either {$mode delphiunicode}or better change the string declarations from string to unicodestring.

Ok - but at what point? TRegistry.GetValueNames populates a TStrings instance (I'm giving it a TStringList instance), and TRegistry.ReadString takes a String parameter as far as I can tell... where can I put a UnicodeString into the process?

There is one person who will try to explain otherwise, don't believe him, do what I say. Then it works.

 ;D

engkin

  • Hero Member
  • *****
  • Posts: 3112
Change your string type to AnsiString or UnicodeString. This looks like UTF16. FPC can handle it (Lazarus too,but not without manual intervention) so use one of the FPC supported string types when moving Delphi code. If it is a recent Delphi, use either {$mode delphiunicode}or better change the string declarations from string to unicodestring.

There is one person who will try to explain otherwise, don't believe him, do what I say. Then it works.

I think you are wrong. This bug was report two months ago, and got fixed. It used to use ANSI version of Windows functions, now it uses the unicode version.

idog

  • Full Member
  • ***
  • Posts: 121
    • www.idogendel.com (Hebrew)
This bug was report two months ago, and got fixed. It used to use ANSI version of Windows functions, now it uses the unicode version.

I forgot to mention I had IDE v1.8.0RC1. I see now that winreg.inc in my installation has the issue as reported, and it's the same in RC4.

This definitely looks like the cause of my problem, but it persists even after downloading the new winreg.inc and running a "Clean Up + Build All". How do I incorporate the bug fix into my installation?

Thanks again,

taazz

  • Hero Member
  • *****
  • Posts: 5368
This bug was report two months ago, and got fixed. It used to use ANSI version of Windows functions, now it uses the unicode version.

I forgot to mention I had IDE v1.8.0RC1. I see now that winreg.inc in my installation has the issue as reported, and it's the same in RC4.

This definitely looks like the cause of my problem, but it persists even after downloading the new winreg.inc and running a "Clean Up + Build All". How do I incorporate the bug fix into my installation?

Thanks again,
By copying the code to a custom unit until a new version of fpc is released it has nothing to do with lazarus and lazarus does not recompile fpc at all, you have to do it manually using make.
Good judgement is the result of experience … Experience is the result of bad judgement.

OS : Windows 7 64 bit
Laz: Lazarus 1.4.4 FPC 2.6.4 i386-win32-win32/win64

engkin

  • Hero Member
  • *****
  • Posts: 3112
This bug was report two months ago, and got fixed. It used to use ANSI version of Windows functions, now it uses the unicode version.

I forgot to mention I had IDE v1.8.0RC1. I see now that winreg.inc in my installation has the issue as reported, and it's the same in RC4.

This definitely looks like the cause of my problem, but it persists even after downloading the new winreg.inc and running a "Clean Up + Build All". How do I incorporate the bug fix into my installation?

Thanks again,

I searched the forum for "How to recompile one FPC package".

Follow the instructions in the link. Use a console, set the path to, and only to, FPC binaries. You most likely to have other make.exe files which will not work.

idog

  • Full Member
  • ***
  • Posts: 121
    • www.idogendel.com (Hebrew)

I searched the forum for "How to recompile one FPC package".

Follow the instructions in the link. Use a console, set the path to, and only to, FPC binaries. You most likely to have other make.exe files which will not work.

I was afraid of getting this answer... :) I'm a complete noob with makefiles and such.

The example in the link is for compiling the fcl-web package, at \fpc\2.6.4\source\packages\fcl-web\src\base . I think I need to compile fcl-registry, but it doesn't have a "base" subdir, and running make in a higher directory where there are make files ("fcl-registry" itself) says "Fatal: Can't find unit system used by fpmake"

In fpmake.pp there's a "uses fpmkunit;" line, but I have no idea where to continue from here... ?

idog

  • Full Member
  • ***
  • Posts: 121
    • www.idogendel.com (Hebrew)
For anyone following, I finally managed to do this.

First, you have to download all the source files from the updated package fcl-registry (not just winreg.inc that appeared in the link above). Then you have to run fpc on the .pp files, then use fpmake - first to build everything and then to install it.

The process is explained, more or less, here:
http://wiki.freepascal.org/FPMake

It wasn't easy or friendly (at least for someone like me who doesn't build fpc/lazarus on a daily basis...) but at the bottom line it works, the TRegistry class can now read Unicode strings and retrieve the proper "COMx" names.

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
It wasn't easy or friendly (at least for someone like me who doesn't build fpc/lazarus on a daily basis...) but at the bottom line it works, the TRegistry class can now read Unicode strings and retrieve the proper "COMx" names.
1.  New features are not bugs
2. This seems to be back-ported to fixes which means it will be in 3.0.4 at least.. and in 3.0.2 fixes.
3. Building either fixes or trunk is easy. You only have to learn it once!
4. Don't use unsupported versions of Fpc or Lazarus. New features are new features.
Specialize a type, not a var.

idog

  • Full Member
  • ***
  • Posts: 121
    • www.idogendel.com (Hebrew)
Re: Reading Registry key by name fails for specific name (string encoding issue?)
« Reply #10 on: September 26, 2017, 01:47:41 am »
It wasn't easy or friendly (at least for someone like me who doesn't build fpc/lazarus on a daily basis...) but at the bottom line it works, the TRegistry class can now read Unicode strings and retrieve the proper "COMx" names.
1.  New features are not bugs
2. This seems to be back-ported to fixes which means it will be in 3.0.4 at least.. and in 3.0.2 fixes.
3. Building either fixes or trunk is easy. You only have to learn it once!
4. Don't use unsupported versions of Fpc or Lazarus. New features are new features.

1. Ok, "bug" was a wrong term for this, sorry. However, calling Unicode support for Windows Registry a "new feature" - well that depends, since when is Windows itself supporting Unicode in the registry? Is it really a new FPC feature, or an old overlook that finally got addressed?

3. Or a couple of times, hopefully. I still don't think I can do this without consulting my written records  :)

4. That's tricky. I wrote my original program about two years ago on an official FPC/Lazarus release, but because something changed in Windows (a device driver assigning Unicode registry key names?) the program doesn't work properly anymore, and I can't fix it without applying yet-unsupported(?) patches. It's either that or looking for another solution altogether.



 

TinyPortal © 2005-2018