Question: on ProgID of controls

[Harsh Gupta]

Hello,

I asked a question yesterday on dynamically adding and removing RTB controls and not normal/default controls of VB, and that's where I came across the ProgID thing. Link here.

So did a bit of RnD on ProgID. Searched the Reg Editor and noticed that almost all controls we use, the Reg Edit. has 2 ProgIDs, one with .1 and another without .1 but both having same CLSID, and further digging into the CLSID revealed that the ID with .1 has a Key [VersionIndependentProgID], its value being the ProgID without .1.

From ProgID on VBAccelerator

When you request an instance of the cFlatControl class, COM looks up the ProgID "vbalFCtl.cFlatControl" which gives it the GUID of the object. COM can then locate the GUID and therefore the path to the object. This is where the problem arises with two objects with the same ProgID. If you create a new version of the Flat Control DLL, say it either has with different methods or it is compiled in VB6 instead of VB5, you will automatically generate a new GUID. However, if you don't change either the project name or the class name, you will overwrite the existing ProgID with your own version. Anyone else's code which expects to get an instance of the object suddenly gets routed to the new version, and their code may then fail depending on what you've done to the existing class.

Talking about RichTextLib.RichTextBox, if I make my own version of RTB and name it RichTextLib.RichTextBox.2, then will it:

1) Generate a new progID? or

2) Overwrite the old progID (i.e. overwrite the RichTextLib.RichTextBox.1)? or

3) Rest in harmony with the default two?

Thank you.

[Harsh Gupta]

Hello!!