Our other option is to replace the controller which is fairly expensive especially considering we are replacing all the hardware in a year. We are waiting to hear back from the vendor to see if we can roll back the software to the previous version which worked. After spending a couple hours on the phone with the vendor, their "fix" was to have us grant admin rights to all users. We discovered that the software update was written with active-x controls that must be run with the user as an administrator. Since the update, none of our end users could access the web interface. Our end users (Win7pro) access the system through a web interface which must be IE, Chrome and Firefox are not supported. It was on a WinXP machine and the OS was upgraded to Win7pro. But I'm still interested in pursuing this if I can.A vendor just updated the software on an old voice recorder which will be replaced next year. So far I've just written a patch that'll install the OCX to a default location and register it without worrying about removing the old one if it's elsewhere. I suppose I should have done it manually, but too late now. But when I make a change to the binary compatibility I don't think it ever unregisters the old ones. If the GUID is the same, it's no big deal. It automatically registers the OCX when I build it. I think there are multiple iterations of it in the registry because of VB6. My patch could check each of those directories, but that seemed less elegant, since I know that Windows has to keep track of the location registered files. It has the potential to be in one of several installation directories, and that's only if the client didn't change the install path completely. It's a custom OCX, but it's included in more than one of our applications. After that, use the same app to register the version in the location you decide on. This is done by Regsvr32.exe executable with /U syntax. The first thing to do is to clean out the registry of all previous instances. There should be no need to muck with the registry in fact, it is generally ill advised. It should only exist in one location on a target system so finding it is not an issue. If this is a custom OCX that you have written, then the responsibility of placement and management is yours. I guess I could just use VB's packags and deployment wizard, but it seems there must be a simpler way. It's been through a few iterations, so there are multiple listings for it in the registry. I'm trying to figure out how to find the GUID of the control. Wandergeist: Yes, the new version is binary-compatible, so I could just put the new version anywhere I want and register it. Now, search for that GUID in HKLM/Software/Classes/CLSID - you will find a node that contains a key for InProcServer32 whose value is the path to where the OCX was registered. Inside that node will be a CLSID key with the GUID value for your control (make sure you use. In regedit, search for the progid for your control (this will be ntrolname) - it will be in HKLM/Software/Classes/ You can do it manually with Regedit, and then (if necessary) go back and write something using the registry API to do it for you. If you really want to do it manually for some reason, it's not that hard to figure out. It's also possible to obtain the GUID that VB gave your control, but as long as you specified you wanted to remain compatible with your old version (and made sure you did so) VB takes care of this for you. You know, you can supply an updated version and, if it is completely backwards compatible, and you use the same GUID for it (which VB6 will do if you haven't made it incompatible and you set the versioning correctly) regsrvr32 or your install program should replace the entry in the registry for the old OCX with the entry for your new one, automatically.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |