Article ID: 200626
Article Last Modified on 8/27/2002
APPLIES TO
- Microsoft Visual Basic 5.0 Enterprise Edition
- Microsoft Visual Basic 6.0 Enterprise Edition
This article was previously published under Q200626
SYMPTOMS
Visual Basic allows you to run only one UserDocument in the integrated development environment (IDE).
CAUSE
There are two sets of uniquely different clsid entries made. The only similarity being the globally unique identifier (GUID) data value.
These are, in fact, two separate programs. However, these programs can mislead programmers into believing they are the same because:
- Visual Basic has no way of determining whether or not an existing copy of the .exe exists in the registry.
- The programmer is not aware of the implications of creating more than one instance of an .exe or .dll file.
- The programmer is also not aware of the need to delete existing registry entries before creating a new .exe or .dll file.
- The programmer can not assure project success when a definitive distinction between an original and a modified .exe file is not made before any registry attempts are made. For example, Project1 could not be confused with P1V1 before CLSID's have been created for that .exe file.
NOTE: Even after both the .exe file and the UserDocument on the desktop were renamed, both worked. The registry showed the change in the name of the .exe file. However, the GUID's default value shows the
following:
Name Data
(Default) Project1.UserDocument1
It is, indeed, the ClassID that links the Userdocument with the .exe file,
not it's name.
The three UserDocuments left in tact, in their unique folder, run from that folder once the URL switches to that folder. In fact, as soon as the real UserDocument1 of that group is used, both UserDocument2 and UserDocument3 display the value shared by the global variable in their module.
What makes this behavior easy to trace is the fact that the first userdocument you run from the desktop is the only one that initializes the information.
The complete, fully functional project passes the information to a module where it was declared globally. The orphaned twin of UserDocument1 on the desktop is exposed when the numeric value to be displayed by UserDocument2 and UserDocument3 returns a 0.
In conclusion, with the exception the Userdocument1 on the desktop asks if you are sure, without the aid of the Module global variable, it would appear as though both UserDocument1 on the desktop and UserDocument1 inside the folder are one in the same. Renaming both the desktop UserDocument and the EXE changes nothing.
RESOLUTION
Programmers need to check for and delete all traces of any existing registry entries when a new release of an .exe file, .dll file, Class, UserControl, or UserDocument is about to be tested outside the integrated development environment (IDE).
STATUS
Microsoft is researching this behavior and will post new information here
in the Microsoft Knowledge Base as it becomes available.
Additional query words: kbDSupport
Keywords: kbactivedocs kbprb KB200626