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

Register ole controls

In the overview it said that this app will allow ole controls to be registered, how is that done.

At the end of the help it says re SRPLauncher.ocx...'Because this is an OLE control, it will have to be registered. From a command line, type the following', sounds a bit strange to say 'type the following' when this 90% of the time will be setup via downloaded install by the user.
Where the whole dilemma of registering ole controls come into it when say a shortcut is put on another pc for network access and the have to rightclick 'run as adminstrator' which then comes up and asks for a password that the users know nothing about!!!!

Comments

  • Barry,

    Keep in mind that different workstations will need to register the controls on their own. It is possible to run an installer on each machine to do this, but sometimes it is easier to manually register files.
  • I have all the registrations in my 'startup' ssp.
  • This is the bit I was referring to:
    "Automatic Registration"
    The SRP Application Launcher can automatically and silently register OCX and DLL files. This is especially useful for application updates or for users unfamiliar with the finer details of OLE technology. "

    So, then you would still have to run as administrator, I was assuming you did some api trick to temp run as administrator - bugger.
  • @DonBakke what response can you give me re my last question?
  • @BarryStevens what question specifically? It seemed to me that this thread ended with your understanding of how things worked.
  • >>but sometimes it is easier to manually register files.
    I thought that was negating the applauncher registering.

    Ok, so if each workstation has the 'applauncher' shortcut, then , if the controls need to be registered (eg. First Time install), they would 'run as administrator' - Correct? and that would do the job.
  • One of the processes must have elevated rights. In this case the launcher would get it and then be able to register the files behind the scenes.

    Note that this feature does not look to see if a control is already registered. It simply registers any controls noted in the INI file. When we introduced this feature the intent was to make it easier for teams to deploy new OCX files into the OpenInsight folder and then just rely upon the launcher to handle the registration process. Current best practice is to not install OCX files in the OpenInsight folder for multi-user systems but rather in local paths on each client. In these cases the launcher won't be as useful.
  • >>Current best practice is to not install OCX files in the OpenInsight folder for multi-user systems but rather in local paths on each client

    Never heard of that before.
    Mine have always been from the server oi folder, registered in the menu startup (if elevated).

    Why is it best practice, sounds like an update nightmare to me.
  • @BarryStevens I strongly encourage (read nicely insist) that the clients IT make the ocx registration part of each users windows login script. This includes copying the file from a given location on the server to a local drive. That means whenever I want to update the srpcontrols, I simply put the latest copy in the OI directory. I can do that at anytime because it's never locked and then I can be confident that each user is using the latest copy from the very next time they login to their pc.

    In laymans terms, whenever a user logs into their pc, amongst whatever else that goes on, the login also
    • copies srpcontrols.ocx from OI directory to say c:\revsoft
    • unregisters srpcontrols.ocx
    • registers srpcontrols.ocx
    That may sound excessive because we don't update the control that often but there's no real overhead and it puts my mind at ease knowing which version each user is using. Plus it removes the elevated rights issue or at least removes it from our concern.

    I certainly didn't come up with this idea and I suspect I'm not the only one that takes this type of approach. Worth considering.
  • edited October 2019
    >>Current best practice is to not install OCX files in the OpenInsight folder for multi-user systems but rather in local paths on each client

    Never heard of that before.


    I'm not disagreeing with your statement, but since you are such an avid participant on our forums I want to make sure you are aware of previous comments we've made on this issue:

    Registering SRPControls.ocx

    OLE.CellImage slow on Windows 10

    OLE.CellImage slow on Windows 10 (2nd mention)

    We state this in our Using OLE in OpenInsight white paper which was published in 2003.

    It is also documented in our Installation and Upgrading Wiki documentation page.

    Once upon a time I had a link to a Microsoft article that explained how ActiveX controls fall into the category of a "client side" component. As such, it is expected to be installed on a local workstation (or Terminal Server) instead of a network share.

    You are correct: client maintenance is always a nightmare. However, it's the nature of the beast when dealing with anything client/server related.

    While your mileage may vary, here are the practical reasons why you want to avoid registering controls on the network share:
    1. Network lag can cause communication interference with ActiveX controls. This can cause crashes (which was a topic discussed in one of the above discussion threads).
    2. Network shares can change which means all clients will instantly break.
    3. Controls that are loaded through a network share are locked and unable to be updated. This is the problem with our DLL files (like SRPUtilities.dll). Installing controls locally avoids this and allows each workstation to be upgraded independently without forcing everyone to log out of OI.
    4. Registering ActiveX controls on a network share still requires elevated permissions, but this usually means the elevated permissions do not have access to the mapped drive since this is established under a different user context. You can get around this by working with UNC paths, but many systems still use mapped drives.
    Those are issues I can recall off the top of my head. I am sure there are a couple more reasons I've forgotten.
  • Ok, thanks, I never picked up on the relevancy of the points being made in some of those.

    Requiring non elevation is my takeaway from this and @AusMarkB method
  • @AusMarkB how do you copy your files in the startup app?
  • @BarryStevens, I think you may have misunderstood or misread this
    that the clients IT make the ocx registration part of each users windows login script


    I don't do anything. The copying and registering occurs when the user logs into Windows itself, not any app. There's no OI code involved. That's why it is the clients IT dept/consultants responsibility. They have complete control of the environment so if there are any issues like in your other thread, it is up to them to resolve them because "they have the power"
Sign In or Register to comment.