Playing with Compatibility of OCX control

[Davor Geci]

Hello,
I'm testing one of my ocx controls, what will happend if the Compatibility is broken.
There is a very good discussion about that:
http://www.vbforums.com/showthread.p...98#post2203498

The problem is that I broke compatibility and now can't get rid of double entry of my control in VBA Additional controls


How to get rid of this old ClassID

[DataMiser]

I would think that you would need to unregister the old one if possible or manually remove the entries from the registery

[Davor Geci]

Hello DataMiser, Thnx for reply,

I've tried Unregisre / Register, no luck.
I've also tried to delete all .EXD files (office use this as internal reference to used controls in projects), no luck. It solved some other problems but not this duplicate entry.

[dilettante]

I would think that you would need to unregister the old one if possible or manually remove the entries from the registery

This is almost certainly what has to be done. It can be difficult to accomplish if the "old" OCX is gone so that you can't use its self-unregistration entrypoint to remove the correct registry entries because they aren't all under some single registry key.

It takes incredible diligence to avoid creating these orphaned registrations. Microsoft didn't worry much because when VB5 (and then VB6) came out they figured novice screwups would be paved over by re-installing Windows from scratch.


Then people began doing "upgrade installs" of Windows and for that matter keeping an old version of Windows far longer than they were expected to anyway. A clean install of a new Windows every 2 to 3 years had been considered normal, complete machine replacement every 3 to 5 years was considered normal. This changed as more consumers bought PCs and businesses got stingier and more hidebound, so Microsoft and 3rd parties began providing "registry cleaners" to deal with orphaned registrations and similar registry issues.

Of course Microsoft "pulled" their reg cleaner because they realized it could cause far more harm than good. If you are willing to grit your teeth and download and run one of these yourself anyway... it may well clean the problem up but you need to be prepared for the possibility that it may break something else at the same time. .Net registration seems particularly fragile and can no longer be repaired post-XP, so you may end up reinstalling Windows from scratch anyway.

[dilettante]

I've tried Unregisre / Register, no luck.

This won't do anything good. Probably no harm though. You must unregister the old OCX.

I've also tried to delete all .EXD files (office use this as internal reference to used controls in projects), no luck. It solved some other problems but not this duplicate entry.

No idea what those are (something like VB's .OCA typelib cache files?) but they probably won't make any difference at all.

[Davor Geci]

Hello dilettante, thnx for reply.

And thnx for a detailed explanation. So it is important that my installer first always !! unregister the old ocx, because it will be a big problem otherwise.
''''''''''''''''''''''''''''''''''''''''''''''''''''''''

Regarding .exd files:
I'm also playing with Office - VBA.
From Microsoft:
https://support.microsoft.com/en-us/kb/932349

If you are using Office Visual Basic for Applications, you may also need to delete the cached versions of the control type libraries. To do this, search your hard drive for ".exd," and delete all the .exd files. The .exd files will be re-created automatically using the new controls the next time that you use VBA.

[techgnome]

This may be a matter of opinion, but personally I think the OCXs should be set with binary compatibility so that they can be swapped out a lot easier. Then you can roll out newer versions w/o having to uninstall the first one. Unless it's been marked for compatibility, each time you build, it gets a new classid, which is then used by the registry. This is what's causing the duplicate entry in your list... one of those points to the old classid. Setting compatibility keeps that in check, as long as you don't do anything so drastic to completely violate the original interface. Typically this means, adding stuff, OK... removing something public (like an event or method or property) eeeehhh... not so much - this is how things get depricated. You can stop code behind those events, but they need to remain as part of the public signature.

But again, it's probably a matter of opinion.

-tg

[dilettante]

Manitaining binary compatibility is a good thing, even if hard to do. And sometimes you can't - a change you need to make might only be possible by breaking compatibility. One way to limit that is to create a new Class or UserControl based on the old one and leave the old one there. So you can end up with a Fidget control and a Fidget2 control that has the new interface and behavior.

This is best when you have a shared DLL/OCX used by multiple programs. When program A needs Fidget2, Program B can still make use of Fidget when the DLL or OCX is updated for Program A.

At some point you'll have a new Fidget3 and you can delete the original Fidget from the library once Program B moves to Fidget2.

But it is far better to do as much planning in advance so that your OCX or DLL is fairly well established before you ever publish it. That makes subsequent interface compatibility breaks less common.

A good deal of space is spent in the VB6 documentation covering these topics.


A decent packaging tool will make it difficult to avoid the unregister/replace/re-register cycle on an update install. However a lot of things people are using to build legacy scripted setups leave all of the details in your hands, making failure the default option. They may not even support the concept of an update install.

Packaging and deployment can be as difficult to get right as writing the programs in the first place.