Registering SRPControls

AusMarkB

When registering the srpcontrols, what is it that determines where in the registry it ends up?
An alternate question is how can I programmatically find the currently registered version of the control?

I utilised the srp_Registry function to determine the location of the currently registered control and it appeared to work fine until I ran the same process on another machine and it returned null. That was because the control wasn't in the part of the registry I was expecting and had coded for.
So whilst I was looking in 'HKCU\Software\SRP', for this particular user, a control 'F' located it in 'HKCR\CLSID\'

Not sure how I am meant to find it there.

Any suggestions?

DonBakke

Mark,

The short answer to your first question is that Microsoft determines where it wants to store registration information. I don't know the specific rules although I know 32bit versus 64bit machines will handle this differently.

For your second question, does this thread help?

AusMarkB

Hey Don,

Yes and No.

I found that today, so I used it and then concatenated the registered path so if the version came back different from different machines, I could better understand why.
As it turned out, the version was the same but the paths were different because the registry locations were different. So basically I got the reverse outcome of what I was attempting to achieve.

AusMarkB

What's more, I thought I had added to that thread today myself but it doesn't seem to be there.

Perhaps I just forgot to click 'Submit' :-/

DonBakke

Mark,

I neglected to mention that the first path you provided, HKCU\Software\SRP, is what we create ourselves. This was done sometime ago as a courtesy but it is not required, is not definitive, and does not get used to enable the control to work. As I mentioned before, this is all handled by Microsoft (Windows) when you run RegSvr32.exe.

HKCR\CLSID should be the way to go.

AusMarkB

Thanks for the clarification and I re-read my first post and the alternate question really should have been how do I programatically find the 'path' of the currently registered control.
How do I do a 'Ctrl F' of the registry?

DonBakke

Mark,

Kevin will probably have to come in and save the day with an answer. The best I can guess is this:

• Trying to find SRPControls.ocx is the wrong approach. This is merely the filename and is not the control itself.
  
• SRPControls.ocx is a bundle of controls so you should just pick one, like SRP Button.
  
• The Registry works off of the ProgID not the control name so focus on SRP.Button.1.
  
• I think you can always find the CLSID from the ProgID at HKCR\ProgID\CLSID.
  
• Then you can navigate to the HKCR\CLSID\CLSID\InprocServer32 to get the path.

Please note that 32bit versus 64bit and possibly Terminal Server versus local PC might alter some of the path in the middle.

AusMarkB

The more I ask, the more I learn.

and what you've said above is certainly applicable for my local machine.
I'll try some variations in time but I'm liking what I'm seeing.

KevinFournier

Here is what the SRP ActiveX Info window does:

• FInd MyCLSIDfrom ProgID using "HKEY_LOCAL_MACHIN\SOFTWARE\Classes\SRP.Button.1\CLSID"
  
• Find file location using "HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\":MyCLSID.

A couple things to note. First, the CLSID for a control never changes. So, once you find it, you could just skip the step that looks up the ProgID. For example, the SRP Button info can always be found at:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{200EC299-E8F5-41A0-8F12-D535168FBFC1} Second, Windows will translate the above registry path behind the scenes on 64 bit systems. So, even though you specify "HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\", it will get translated to "HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\".

AusMarkB

Thanks for the clarification Kevin.
I like it when little mysteries are revealed.

I'm picturing a whole new 'About' page.