A few posts have mentioned this, notably Alan Mailer's problem with Winsock
on 11.09.00.

VB will occasionally change a reference to a Component OCX to a hidden
Reference to an OCA.

eg: I have added the MS Windows Common Controls component (MSCOMCTL.OCX) in
order to use, say, a ListView.
Later, I open the project and forms won't load and ListViews have reverted
to PictureBoxes.
The MS Windows Common Controls component is no longer checked in the
Component's list.

Worse, attempting to check the component returns a "Name conflicts with
existing project or library".

Things now seem drastic - can't add the component, can't run without it.

Opening the VBP file in a text editor reveals the problem.
When a component is selected, the VBP usually includes a line such as:
    Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.0#0; MSCOMCTL.OCX

but now, there is no 'Object' line, but instead a 'Reference' line,

Reference=*\G{583A9649-7F7C-443E-94AD-65868A545AEA}#2.0#0#..\..\WINNT\system
32\MSCOMCTL.oca#Microsoft Windows Common Controls 6.0 (SP4)

Yet this reference does not appear in the Project References list.

Can anyone, Microsoft included, answer when and why VB makes this change?

Regards

Bill Wilson

I had this problem once. Unfortunately, I'm not sure about the real
mechanism that triggers the problem. So, I speculate: VB must be writing
incorrect GUID to a particular component: so, the next time you open the
project, VB finds another GUID for that same component name. I successfully
solve the problem following those steps:

1. Delete all the problematic-object references from the file MyProject.vbp.
This include the line "reference" and the line "object".

2. Open the project. It may display the same error messages.

3. Delete all the controls related to the object problem. Don't worry about
the code you wrote. If you delete controls in VB, it automatically save all
the code you wrote in private procedures in the container form. (If you've
put the control with no code, note the object name: VB will not save its
procedures.)

4. Open the references dialog and check the control/reference you want. You
may notice it will now accept the reference, since there's no longer
misguided GUIDs referenced in the project.

5. Place the controls/objects in the form. Rename them with the same
name/index of the old ones.  Surprise! VB automatically place the code back
to your new controls.

I've run through this problem many times, and rescued my work all of them,
following the above approach. Cheers!

By opening a new project, adding the components/references to the new
project, and placing a dummy control of each control used on the form, you
should get a (new) VBP (and FRM) with the correct object references.  Copy
these to (a copy of) the original VBP file (and affected FRM files) in
NotePad or similar.  This way, placement, sizing and other design time
properties are maintained.

Regards,
Tore.

Another way is search for the correct control GUID in registry and edit the
VBP file overwriting the wrong GUID with the correct one:

All the controls' IDs (by the way, all classes too) are located at
HKEY_LOCAL_MACHINE\CLASSID for Win9x.

All the controls' IDs (by the way, all classes too) are located at
HKEY_LOCAL_MACHINE\SOFTWARE\Classes for WinNT and Win2000.