Join The Works program to have access to the most current content, and to be able to ask questions and get answers from Revelation staff and the Revelation community

At 30 JUN 2000 09:21:49AM Donald Bakke wrote:

Gene Gleyzer, Cameron Purdy or Mike Ruane:

A couple of years ago Gene posted code to get values from the Registry. Below is an example of this code:

Function TEST_REGISTRY(void)

EQU HKEY_BASE$ to 2147483648 ;* 0x8000000

EQU HKEY_CLASSES_ROOT$ to (HKEY_BASE$ + 0)

EQU HKEY_CURRENT_USER$ to (HKEY_BASE$ + 1)

EQU HKEY_LOCAL_MACHINE$ to (HKEY_BASE$ + 2)

EQU ERROR_SUCCESS$ to 0

declare function RegOpenKey, RegCloseKey, RegQueryValue, GetPointer

declare subroutine RegCloseKey, RegQueryValue

hKey=0

stat=RegOpenKey(HKEY_CLASSES_ROOT$, 'AcroDist\shell\open\command':\00\, hKey)

if stat=ERROR_SUCCESS$ then

szBuf=str(\00\, 512)
cbBuf=512
stat=RegQueryValue(hKey, '':\00\, szBuf, cbBuf)
stat=RegCloseKey(hKey)

end

return szBuf

This works fine when I want to get the default value for this subkey. But when I want to get a specific value for this subkey the RegQueryValue function always fails. According to the API documentation all I am supposed to do is place the name of the value I want in the second parameter:

stat=RegQueryValue(hKey, 'test':\00\, szBuf, cbBuf)

However, whenever I put anything other than a null here the RegQueryValue functions fails and I get no results in szBuf. Can someone point me in the right direction?

Thank you,

dbakke@srpcs.com

SRP Computer Solutions


At 30 JUN 2000 05:33PM Cameron Purdy wrote:

Don,

To be safe, instead of:

szBuf=str(\00\, 512)

cbBuf=512

Use:

cbBuf=len(szBuf)

(In case you change the first line.)

Instead of:

return szBuf

Use:

return szBuf1,\00\

(To only keep the data.)

Then you can check the return length.

Now, what you might be seeing is that the 16-bit registry support can't access all the items in the W9x registry. If you are sure the key is correct, then that is a probability. Can you get any data back?

Cameron Purdy

Revelation Software


At 30 JUN 2000 09:13PM Donald Bakke wrote:

Cameron,

cbBuf=len(szBuf) return szBuf1,\00\

Thank you. I left the code in its original format for your (or Gene's) sake. Since he wrote it I thought it would be helpful to post it in it's original format.

Now, what you might be seeing is that the 16-bit registry support can't access all the items in the W9x registry.

I can accept this if it is actually the issue. However, it appears from all the API documentation that I have that these functions should work. If it is purely because they are being launched from a 16-bit shell then so be it, but this doesn't seem to limit (AFAIK) any other API functions that have 16-bit registry support.

Can you get any data back?

Only if I don't put anything within the quotes of the second parameter of the RegQueryValue function. In that case I always gets the default value of a registry key (assuming something was in there to begin with.)

The API documentation suggests that putting the name of the key in this parameter will retrieve the value for that key. When I do this, however, it returns a null everytime. I was somewhat hopeful that there is a way to do this since Gene was originally responding to a question about getting the value of a registry key. He seemed confident that this would work and posted the aforementioned code. Unfortunately, the example left the key value blank and I haven't figured out the correct way to pass the key (unless, of course, he knew that couldn't be done.)

If this can be positively confirmed, either way, I would appreciate it. This request is for a project we are co-developing in and I will be expected to provide a formal response if this can't be accomplished. If this is not possible then we will have to restructure another piece of the application (which is developed in Delphi) to store it's settings in another manner like an INI file. The team and the project owner would rather avoid making concessions if at all possible.

Thank you for your attention to this.

dbakke@srpcs.com

SRP Computer Solutions


At 06 JUL 2000 08:12AM Cameron Purdy wrote:

Don,

Next step then is to check the other values, like the handle and the status, that result from those calls.

Cameron Purdy

Revelation Software


At 06 JUL 2000 09:22AM Oystein Reigem wrote:

Cameron,

For those of us who are listening in - is there a piece missing in this thread?

- Oystein -


At 06 JUL 2000 10:22AM Donald Bakke wrote:

Cameron,

Next step then is to check the other values, like the handle and the status, that result from those calls.

Okay, I want to make sure we are on the same page here. I know my handle is correct because I have successfully executed this process when I leave the subkey parameter as null. That is to say, if there is data in the default subkey that gets returned without any difficulties. The only thing I change is the name of the subkey I want to examine. At that time the result is always null. I have played with upper and lower case to no avail.

Did I understand your suggestion correctly?

Thanks,

dbakke@srpcs.com

SRP Computer Solutions


At 07 JUL 2000 12:11PM Gene Gleyzer wrote:

Don,

I tried to get the value using the RegQueryValue and it didn't work for me either. The error status I get back is ERROR_BADKEY as soon as the subKey is not an empty string. My guess is that it has something to do with the fact that in Win16 there is just one registry value data type – string (see shellapi.h, symbol REG_SZ) and RegQueryValue API doesn't allow us to communicate this to the corresponding Win32 function RegQueryValueEx().

I'll try to find some clues on the Web, but so far my answer unfortunately is: "functionality is not supported".

Best regards,

Gene


At 07 JUL 2000 01:54PM Donald Bakke wrote:

Gene and Cameron,

Thank you very much for pursuing this for me. I can now provide the team with a definitive response. Regretably this is not the answer we had hoped for, but we can't get what Window's won't supply.

Best regards,

dbakke@srpcs.com

SRP Computer Solutions

View this thread on the Works forum...

  • third_party_content/community/commentary/forums_works/1b7b5d0fb393da678525690e004968c3.txt
  • Last modified: 2023/12/30 11:57
  • by 127.0.0.1