Listview not displaying after reregistering mscomctl.ocx

[Guest]

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?

 

[Rob Oldfield]

Without access to the stuff that you're using, I'm guessing here... but have
you checked the references? More info here...

http://www.mvps.org/access/bugs/bugs0001.htm

 

[Guest]

Rob,

Thanks for the suggestion, but all the references are there. We can even
reproduce the problem I described on our development machines. If we
deliberately remove the references from the project, or unregister
mscomctl.ocx, we get different errors, as expected.

Also, debugging the code when the "no object in this control" error occurs,
we can confirm using the Immediate window there is actually an object there.
And it is only the Listview class which is causing problems. The other
classes from mscomctl.ocx are created without problem.

Phil

 

[Andreas]

Definately not an expert on this.
I avoid ActiveX in Access like the plague.
Are you sure you are using the correct version of mscomctl.ocx?
Last time I used a TreeView, I needed to download the ocx so I could
install it on PC's that didn't have it and found that there were
numerous different versions, not all compatible. Don't have the info
habdy but you can check the version by right-clicking the ocx and
looking at the properties (I think).

Regards,
Andreas

 

[Guest]

Andreas,

Yes, there are many different version of mscomctl.ocx, but I don't think
that is causing the problem. The problem first appeared when our software
was used with Access 2002, whose version of mscomctl.ocx should have been
backwards compatible, but wasn't. We have the right version of the ocx for
Access 2000 on our development PCs, and yet can still reproduce the problem.

I agree about Access though. I am looking forward to working in .Net instead!

Regards,
Phil

 

[Andreas]

I was driving home from work today.
For some reason I thought about this.
Now again, I am not sure as all that stuff is on a different PC.
I seem to remember that there is also an issue with the OS.
In fact, it might be an issue with the OS rather than Access.

Regards,
Andreas