RegQueryValue Sample?

[Intel_C_Intel]

It's very late and I've spent the last many hours fighting with APIs again. Hopefully that is sufficient explaination for my incoherence........

My first question is about APIs that retrieve the system and user name. The usage that works is
Call GetComputerName( Text, Loc(i) )
rather than as it appears in the CVF samples
Call GetComputerName( Text, i )

Is this a bug, an erratum, or am I missing something fundamental?

Since I have that working now, the more important question is about querying Registry Keys. I want to
retrieve the CPU make and speed, which is contained in HKey_Local_MachineHardwareDescriptionSystem
CentralProcessor�ProcessorNameString.

I open each subkey in turn with the Reg_Query_Value access. Each RegOpenKeyEX returns Error_Success. But I have fought for hours to get RegQueryKey or RegQueryKeyEx to work.

Does anyone have a simple working example?
Thanks, and Good Night!

Message Edited by frieler on 03-28-2004 06:38 AM

[Intel_C_Intel]

As usual, a few hours sleep and a careful review of the problem over morning coffee........

Here's what worked for me;

Character :: KeyName*64, SubKeyName*24
Integer (4) :: i, ilen, hKey

KeyName="HardwareDescriptionSystemCentralProcessor�"//char(0)
SubKeyName = "ProcessorNameString"//char(0)
i = RegOpenKeyEx( HKey_Local_Machine, KeyName, 0, Key_Query_Value, Loc(hKey) )
ilen = 64
i = RegQueryValueEx( hKey, SubKeyName, 0, 0, Loc(Text), Loc(ilen) )
i = RegCloseKey( hKey )

>9:34AM
But..... This only seems to work if RegEdit has been invoked from the command line once since system boot (or login, I'm not sure which). This suggests that the "hive" is cached when RegEdit runs, and it is from this cache that the APIs gather data. Is there a way to fill this cache with another API call?

>10:02AM
My "Education" continues....
It now appears that the "cache" fill caused by RegEdit is volatile. After 20min or so, the code above again fails to work. Another command line use of RegEdit, and success immediately returns.
Any insight into this behavior?

>11:06AM
Some additional info.....
Some Keys (hives?) in the registry are indeed volatile, and are only built upon certain system events. Specifically, the one I'm interested is only built at boot up, when hardware discovery is initiated or when the RegEdit app is started. I can start Regedit and then kill it immediately to cause this hive to be built, but it would be much more convenient to have an API call that did this. Some web info suggests RegQueryKeyEx, but I can't find that API anywhere in the CVF distribution. Does anyone know where it is hiding? Any other suggestions?



This still leaves my question about the sporadic use of value and pointer in the fortran interfaces, but maybe if I stare at that a while also.

Thanks, Cliff

Message Edited by frieler on 03-28-2004 11:10 AM

[Steven_L_Intel1]

I can clear up some of the confusion.

Interfaces such as RegQueryValue for which the value argument can be "anything" were initially defined as an address-sized integer passed by value. Thus you needed the LOC() to pass the address of the value buffer.

Somewhere around CVF 6.5 (or maybe 6.1?) we added an IGNORE_LOC attribute which, when combined with REFERENCE, said "if the code has LOC() for this argument, ignore it and pass the argument by reference. We added this to many interfaces so that programming would be more natural. Some examples show the new way, some the old.

[Intel_C_Intel]

Thanks, Steve.
I thought that might be the case, but I make enough bonehead assumptions and mistakes that I was deliberately diplomatic.

I guess I still don't quite understand, though. If the changes to CVF were to make the interface tolerant of the presence or absence of Loc(), why is my specific example functional one way and not the other?

Thanks again, Cliff

[Steven_L_Intel1]

I didn't look at your example specifically - just wanted to clear up the issue about "to LOC or not to LOC". Perhaps someone else can help with your particular issue.

[Jugoslav_Dujic]

Cliff, to my knowledge no CVF's API translation has ever translated LPDWORD (and similar, such as LPUINT) as integer by reference (which would be natural) -- there has always been just integer (by value by implication from STDCALL). Thus, Steve's remarks about IGNORE_LOC and REFERENCE dont' apply.

This translation choice/omission is IMO not fortunate, but at least it's consistent in its inconsistency. That means you have to use LOC() wherever APIs state LPDWORD for an argument. I'd guess that the CVF sample you refer to is simply mistaken.

I didn't look much at your volatile registry hive problem; but I doubt the registry is the way to go -- getting low-level hardware information has always been tricky under Windows. Have you searched the newsgroups?

Jugoslav