Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

Registering SRPControls.ocx

I'm sure there is some mistake I'm making, but I couldn't figure it out and thought you guys could help me out.

I just downloaded the new SRPControls.ocx file after reading about the updated calendar control from Kevin's blog post. I renamed the old .ocx and replaced it with the new one of the same name. We have a window in our application that registers controls, but it didn't seem to work, so I tried registering from the command prompt that I "ran as administrator." and got an error message (attached). I am on a local PC and the ocx file is on a server. "O" drive that you see in the screen shot is a mapped network drive.

When I run our application, the controls work, but the SRP licensing window pops up (attached) every time I interact with a control.

Any thoughts on this? Thank you, wise and helpful SRP friends!

Comments

  • The SRP License message popped up because your license is out of date. I didn't realize you were not getting reminders to renew this license. Obviously it didn't matter since you don't seem to have downloaded and installed SRPControls.ocx for a few years. I'll contact Ray privately to make arrangements.

    I'm a bit confused by your RegSvr32 message. If it did not register for you, then how is it you are getting the SRP License message?

    BTW, registering OCX files on a network drive is not recommended. You should put all client files on the local drive of each workstation.
  • BTW, registering OCX files on a network drive is not recommended. You should put all client files on the local drive of each workstation.
    Didn't realise this. So if I've got 40 users in a workplace, they should all get a local copy of srpcontrols.ocx and subsequently each of them receive an updated copy whenever an update is relevant?
  • In a nutshell, yes. If your workplace is sufficiently large then you might consider implementing a deployment strategy through group policy or similar. I believe it was Jared who wrote this Knowledge Base article on best practice workstation installation.

    I'm curious, if you have not been doing this up till now, have you not experienced any problems with UAC? This is what forced the issue for us. You can't register an OCX without elevated permissions, but elevating the permissions puts the console into a different scope that doesn't have access to the mapped drive. When we researched the issue we found out that Microsoft has always recommended that client-side components should normally be installed and registered on the local machine.
  • have you not experienced any problems with UAC
    I'd be lying if I said "No" but I don't generally consider them problems.
    Why? I've always made the distinction between my role and "I.T."

    So for convenience I will do the install, registration etc if I'm there and I can but if anything problematic pops in the way then the responsibility falls to the respective IT guys as they are the ones responsible for the network and user access. It's then a simple request; user requires clientsetup installed and srpcontrols registered. The "how" falls to them and as long as it works...
  • Armed with this extra info I can now make stronger recommendations
Sign In or Register to comment.