P
Phil Roue
We have an application developed in Access 2000 that uses forms, VBA and
Activex controls including Listviews.
We had a backwards compatibility problem with mscomctl.ocx when our
application was ussed in Access 2002. Listview controls were not displaying
properly. A side note, our application worked without problem in Access 2003.
As a workaround for Access 2002, we distributed the version of mscomctl.ocx
with which we had developed the application in Access 2000.
The workaround was fine except for the following problem, which also
occurred in Access 2000, and which can be reproduced as follows:
1. With regsvr32, unregister and then re-register mscomctl.ocx.
2. Open the application.
3. Forms hosting controls from mscomctl.ocx (other than the listview) are
fine.
4. But forms containing the listview control have a white box where the
listview would be, and any code referencing the listview raises an error
saying "runtime error 2683 There is no object in this control".
5. If you then replace the existing copy of the .mdb with a new copy, the
problem does not occur.
I don't really understand why our Access application is not picking up the
re-registered copy of mscomctl.ocx. My understanding of how COM works is
that applications merely search in the Registry for the ProgID of the COM
component, from that get the CLSID, and from that locate the file for the COM
component.
Do Access applications store additional info about Activex controls that
gets corrupted if the COM component cannot be found?
Activex controls including Listviews.
We had a backwards compatibility problem with mscomctl.ocx when our
application was ussed in Access 2002. Listview controls were not displaying
properly. A side note, our application worked without problem in Access 2003.
As a workaround for Access 2002, we distributed the version of mscomctl.ocx
with which we had developed the application in Access 2000.
The workaround was fine except for the following problem, which also
occurred in Access 2000, and which can be reproduced as follows:
1. With regsvr32, unregister and then re-register mscomctl.ocx.
2. Open the application.
3. Forms hosting controls from mscomctl.ocx (other than the listview) are
fine.
4. But forms containing the listview control have a white box where the
listview would be, and any code referencing the listview raises an error
saying "runtime error 2683 There is no object in this control".
5. If you then replace the existing copy of the .mdb with a new copy, the
problem does not occur.
I don't really understand why our Access application is not picking up the
re-registered copy of mscomctl.ocx. My understanding of how COM works is
that applications merely search in the Registry for the ProgID of the COM
component, from that get the CLSID, and from that locate the file for the COM
component.
Do Access applications store additional info about Activex controls that
gets corrupted if the COM component cannot be found?