I keep seeing this phrase, what does it mean?
One thing in that article said:
An ActiveX control is just a COM component that implements certain interfaces. The implementation of an ActiveX control is normally a DLL file.
Sum Dum Gai
An OCX file is another type of COM DLL too. OCX's are also susceptible to DLL Hell.
If you want to understand ActiveX and COM, one of your best resources would be Chappell's book "Understanding ActiveX and OLE"
The problems of DLL Hell were largely diminished in Win 2000 and then XP.
dll hell refers to the fact that applications would often install their own version of standard Windows .dll's because they couldn't bwe sure you had the up-to-date one. The problem was that those "up-to-date" .dll's would often be out-of-date when you installed the program, and would overwrite a newer version, and stop something else working.
Another good thing to read is just the first chapter of Don Box's "Essential COM". You'll totally understnad DLL Hell after that.
"You'll totally understnad DLL Hell after that."
Most newcomers to VB will get stuck in COM DLL hell reasonably quickly, because the concepts of binary compatibility and references aren't particularly explained well. Even more experienced programmers will still get it from time to time because you have so little control as to the COM stuff going on under the hood.
Better Than Being Unemployed...
I don't think it's been mentionned: As far as you're concerned, the pain about ActiveX controls is that, unlike regular DLLs, sticking the .OCX file in the directory where your app lives doesn't ensure that this is the one that will be used. The reason for this, is that Windows looks up the OCX's path in the registry, not in the filesystem... and Windows (until W2K/XP, but I haven't looked into this) doesn't provide a means to allow more than one given OCX to be located in the Registry.
which is why you should have multiple clsids if the class is different.
But then, generating a different CLSID every time a new version of a control comes out breaks compatibility... and since, if I understood COM at all (not sure :-)), one of COM's virtues is providing multiple interfaces, each one mapping to a different revision number... it makes sense that the CLSID wouldn't change.
of course. if the interface is identical as the COM contract reqires, and the class only provides new interfaces, then you shouldn't change the ID. but most people don't do that. so i'm suggesting v1 has clsid1, v2 installs clsid1 (w/full backwards compatiblity) and clsid2, and anything requiring v2 calls clsid2. and if you install v1 on top, it only blows away the backwards-compat part of v2, which won't hurt anything.
MS used to want to understate the problems associated with different COM servers providing for the same CLSID. Then when .NET came out they wanted to convince all the COM programmers to switch so they started overstating it instead. This is why you keep hearing the term "DLL Hell" :)
Fog Creek Home