Bug in Get Registry Subkey script command?

I have noticed a bug in the Get Registry Subkey script command. When using this command to retrieve the name of the subkey (by providing the index number), it will skip over ANY subkey if that subkey’s name begins with the at symbol (@). I’ll show you a quick example below.
First of all, let’s say these entries below are in the registry:

HKEY_CURRENT_USER
> AppEvents
> Console
> SoftwareCatalog
> .NET Framework
> @Risk 6.2
> AskToolbar
> BatmanBegins


So if I run the following Get Registry Subkey script command, I should get a return value of “4” placed into the %TMP_NUM_SUBKEYS% variable.

Set Variable %TMP_NUM_SUBKEYS% to FUNCTION: Get Registry SubKey (“0”) from HKEY_CURRENT_USER\SoftwareCatalog

If I then issue the Get Registry Subkey script command below to get the 1st subkey’s name under HKCU\SoftwareCatalog, this command will return a value of “.NET Framework” into the %TMP_SUBKEY_NAME% variable.

Set Variable %TMP_SUBKEY_NAME% to FUNCTION: Get Registry SubKey (“1”) from HKEY_CURRENT_USER\SoftwareCatalog

Now, here’s the bug . . . If I then issue the Get Registry Subkey script command to get the 2nd subkey’s name under HKU\SoftwareCatalog, this command will return a value of “AskToolbar” instead of the “@Risk 6.2” that I would expect. (That is a real software application’s name, by the way.)

Set Variable %TMP_SUBKEY_NAME% to FUNCTION: Get Registry SubKey (“2”) from HKEY_CURRENT_USER\SoftwareCatalog

The command seems to act as if the 2nd subkey does not exist because its name began with a “@” symbol. It doesn’t seem to mind if the @ symbol is anywhere else in the name, only if it’s the first character in the name.

Jerry,

we'll check it.

Friedrich

Jerry,

would it be possible to export your HKEY_CURRENT_USER\SoftwareCatalog keys/subkeys/values to a .reg file and send it to support@lindersoft.com so we can import it here? SetupBuilder uses pure Windows APIs to process the Windows registry and there is no code in the runtime that treats '@' items differently.

This is what I see in our tests (see attached screenshot). It retrieves the @Risk 6.2 sub-key without any problem.

Thanks,
Friedrich

I'll be sending something to you in the next day or so.

Thank you, Jerry!

Friedrich

You may disregard this post or even delete it. Unfortunately, I can't seem to recreate this error. That's actually a good thing, but I know I wasn't imagining it. When this "error" originally happened, I was running the same kind of script commands that you gave in your example back to me. I made sure I could recreate it about a dozen times before posting anything because there's nothing more embarrassing than posting a bug report and finding out that there's nothing wrong. However, I put this away for a few weeks and when I came back to it, I can't recreate it. So, I'm just going to chalk it up to something I did or some condition I created that was giving me the odd result I was getting rather than it being something buggy with the code.

Apologies.


Jerry Shannon