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.