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!!!!
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
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.
So, then you would still have to run as administrator, I was assuming you did some api trick to temp run as administrator - bugger.
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.
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.
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.
In laymans terms, whenever a user logs into their pc, amongst whatever else that goes on, the login also
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.
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:
Requiring non elevation is my takeaway from this and @AusMarkB method
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"