Access97: Latest MS dev tools break existing Access installations
The problem is that ComCtl32.ocx is a common and widely used ActiveX
control. My application is using the ListView, TreeView and ImageList
controls that it includes.
ComCtl32.ocx is created by Microsoft and included as a distributable
component of many of their development tools (Office Developer, Visual
Basic, Visual Studio etc). This means that every Tom,{*filter*} and Harry is
shipping it with their applications.
I use and ship V5.01.4319 which comes with Office 97 Developer Edition (ODE)
SR-1.
I now know that Norton Internet Security 2001 is the package which upgraded
my version to 6.00.8105. This new version has a digital signature. I suspect
that this is the only significant change and has come about because of
Win2000 installation requirements.
What I really want is a copy of the latest version from Microsoft which I
may legally distribute under my ODE licence.
Unfortunately, the Microsoft line appears to be that Access 97 was tested
with 5.01.4319 and therefore it is not known whether 6.00.8105 will work
correctly with ODE 97-SR1. Users of ODE 97 should continue to use the
version shipped with that package.
In practice this is saying "Do not build your app with Norton Internet
Security 2001 on your development platform". This is not very practical. I
don't want to boot onto a different partition to safely access the internet.
But this Microsoft stance is more than just an inconvenience for developers.
To add to the complexity, the version of the TypeLib registered for an
ActiveX control is independent of the file version. For example,
ComCtl32.ocx 5.01.4319 registers TypeLib version 1.2, whereas 6.00.8105
registers version 1.3.
The theory is that if the OCX file uses the same GUID, the TypeLib it
registers should be upward compatible with previous versions. There have
been classic violations of this rule (namely with ComCat.dll breaking
Internet Explorer V3) but most applications rely upon this development rule.
Unfortunately Access does not rely upon this rule. I think it remembers the
TypeLib version as well as it's GUID within its References collection. If
either changes, it breaks the reference which must be rebuilt. If the
application is a turnkey product in the hands of an end user, it simply
breaks.
Hardin Brothers published some code in the July 1999 Smart Access Newsletter
which detects and fixes this situation. However this method is not supported
by Microsoft themselves. Without this saving code the situation is as
follows:
1) Microsoft have released a new version of ComCtl32.ocx with a new TypeLib
version for an existing GUID
2) Access 97 will not work if the TypeLib of one of its ActiveX controls
increments its version
3) This means that Microsoft have effectively rendered all previously
deployed applications developed in Access97 unusable. In other words, if you
install a package developed with the latest Microsoft development tools,
previously developed Access 97 applications will break.
4) To remedy this situation Microsoft should:
a) Publicly release the latest version of ComCtl32.ocx to the Access 97
developer community.
b) Regression test it against the last available service release of Access
97 so that we know that it will work.
c) Provide a mechanism for repeating the process for future releases of all
its ODE 97 ActiveX controls.
I believe that the Access 97 development community is still of major
significance. I suspect (although I am not sure) that the same problem
exists with the Access 2000 platform.
If Microsoft is serious about supporting its developer community, it must
deal with this situation.
Best Regards
Neil
--------------------------------------------------------
Neil Sargent
Smart IT
--------------------------------------------------------
