Microsoft has an update file, COMCTL32.EXE dated 4/14/97 that was to
update to version 5.00.3828

There seems to be a Double registration schema for Object Libraries in
the Windows/Office 97 system.
Register #1 in the OS Registery.
Register #2 in the VB/?? Office97 Application

So... Change the entry in one without changing the other, results in
BAD!

RE Author in VBPJ  Mr. Karl Peterson.
He referred to a condition in a Q&A column in August 97 Visual Basic
Programmer's Journal (pg. 89)

If you update with a new file that is the same name and is only an
updated version like comctl32.ocx and register it in the Win95 system
registry, the pre compiled Access, VBA, Excel, etc. Application that had
set a "Object Library Reference" to that Object will fail to load
correctly. This results in many strange Error messages:
"Function not found" etc. Or, like the example in the VBPJ, the forms
lost and/or change the control types.
e.g. Listview to PictureBox

SO...
For the Access 97 application that will not run after the update to:
comctl32.ocx V 5.00 3828 or I guess, to most any
other that changes the INTERNAL VERSION Number,
not the version number one sees in a file property box!

For comctl32.ocx File Version 5.00.3601 the internal version is 1.1 (see
below)
For comctl32.ocx File Version 5.00.3828 the internal version is 1.2

Those Version Numbers are written into the Windows Registery, when the
control is
"Registered" with the O/S. If one only "copies" the new file:
comctl32.ocx, overwriting an
existing comctl32.ocx,  then does not un-register the first and register
the last, then
your have trouble in river city!

Example in an  Access 97, VB Application:

when the menu Tools | Refeneces is used to select the object

Sub givemestrength()
Dim x as long
for x = 1 to Application.references.count
debug.print Application.References(x).Guid & " version " &
Application.References(x).Major & "." & Application.References(x).Minor
& " Path " & Application.References(x).FullPath
next x
end sub

Printed:
{000204EF-0000-0000-C000-000000000046} version 3.0 Path
C:\WINNT35\MSAPPS\VBA\VBA332.DLL
{4AFFC9A0-5F99-101B-AF4E-00AA003F0F07} version 8.0 Path
E:\msoffice\Office\MSACC8.OLB

{6B7E6392-850A-101B-AFC0-4210102A8DA7} version 1.1 Path
C:\WINNT35\system32\COMCTL32.OCX

{00025E01-0000-0000-C000-000000000046} version 4.0 Path
C:\WINNT35\MSAPPS\DAO\DAO350.DLL
{8E27C92E-1264-101C-8A2F-040224009C02} version 7.0 Path
C:\WINNT35\System32\MSCAL.OCX
{2DF8D04C-5BFA-101B-BDE5-00AA0044DE52} version 2.0 Path
C:\WINNT35\MSAPPS\vba\MSO97RT.DLL

Therefore, if an update is done to the O/S Win95, by only replacing the
comctl32.ocx, note the GUID is the same, when the Application is
started, the link is broken because the version number has not
been reset. NOTE: Setting a reference DECOMPILES the *.mdb

======================= Bottom Line is: ========

IF I understand this schema correctly, then EVERY Office97 Application
that sets a reference to a Object Library, must take care of
housekeeping at each Application Load, because, one does not know when
the, say
comctl32.ocx has been updated to a new version. Even though the Binary
is compatible, the hard coded Version # will cause the  brokenLink to
occure.

--
John L. Turner
JCI Inc.
2425 Poca River Road {Lanham}
Poca, WV 25159       voice (304) 776-3675
~~Just because you do not know the answer, does not mean that someone
else does~~