There have been a number of times I've wished I could create a RegistryItem using an HKEY handle that I've gotten from the OS. For instance, the REALbasic RegistryItem class doesn't support remote registries. So instead of writing my own RegistryItem class, I want to use the RegConnectRegistry API to connect to another machine, and then pass the resulting HKEY into a RegistryItem constructor -- voila! I'd have a RegistryItem that I can use for a remote computer.
Alas... but this is impossible currently. What's more, but this will probably never be possible due to an unfortunate, but often useful, quirk of the REALbasic API.
In REALbasic, you can get access to an arbitrary RegistryItem's path as a string. For instance, given a RegistryItem, you can ask for its Path property and use that for display purposes. Internally, this path information is also used for navigating from a child item to a parent item.
Unfortunately, the Win32 doesn't provide you with a way to get a path from an arbitrary HKEY. So if you were to create a a RegistryItem via an HKEY, the Path property would only be able to return an empty string at worst. At best it would return to you the part of the path the item has already traversed via Child or Item.
However, that's not the end of it -- the Parent property would also not work reliably either. There's no Win32 API to navigate back *up* the hive. So you can navigate from a parent to a child, but not from a child back up to a parent. The way REALbasic handle's navigating up to the parent is by making use of the path information that is stored.
So because of these handy APIs, it is unlikely that you will ever be able to create a RegistryItem from an OS handle.
Why would you want a path or parent property for a key on a remote computer?
It seems like if you're using an HKEY handle then you wouldn't be interested in either of those... I would say it seems very reasonable to expect them to not work. But hey, I've been commenting on your blog too much. ;)
@Isaac -- why would you want the path or parent on a local machine? I mean, after all, you had to construct the item yourself which means you already know the path components. It just boils down to ease of use. Instead of requiring the user to keep the path information themselves, we keep it for them so that it's easier to display and navigate. The RegistryItem's navigation scheme comes directly from the FolderItem API. Since they seem so similar to one another, it's easy to move from one to the other without being overly scared.
And you can comment on my blog as much as you'd like! I enjoy it. :-)