thesleepylizard
Programmer
Hi everyone,
I have an ActiveX Control which I wrote and maintain in VB6 - it compiles to a OCX file which I can include in the components screen in other programs. (I'll call it SuperGrid.OCX, containing a UserControl called SuperGrid)
OK. Here's the visible problem: If I need to make a change to the ActiveX control, I open up the VB project for it, make my change, and compile again to the OCX file. Then, after that, when I try to open another VB project which includes this OCX file in the components window, I get the message:
Clicking yes brings up many error messages like:
It gives that error message for each form that uses SuperGrid. I found I can get it up and running again by clicking through each of the error messages, then going into Components and ticking SuperGrid again, and then going into each form that used SuperGrid and inserting the control again. But with 15 screens using it, I'll have to do this each time I make a change and recompile SuperGrid. Kinda... annoying.
====Now for the technical garb.====
I've done some digging around. I'm not 100% clued up on ActiveX, and object IDs and versions and things, but, here's what I've found:
In the myprogram.vbp file, it contains a reference to SuperGrid along the lines of:
The first series of number appears to be the unique class ID, the after that we have #3.0#, which appears to be the version number, and after that I'm not sure what that number is.
NOW, I created a seperate dummy activeX control to try and diagnose what the problem was. I could recompile it to Dummy.OCX, open up a seperate project which included Dummy.OCX, and the class ID recorded in the dummyproject.vbp file wouldn't change. (The version number changed, which VB mentioned when it loaded up, but the class ID never changed, no matter how many times I recompiled). That is correct - the class ID shouldn't change.
But, I performed exactly the same test with my SuperGrid, and I found that when I recompiled it, (drum roll.....) THE CLASS ID HAD CHANGED!!!!!
Summary in techo terms: Each time VB recompiles my SuperGrid.OCX, it is assigning it a new class ID, which is disrupting references to it in other projects.
This is bad, this is wrong, this is a NO NO. This is what is making VB fail to recognize it in other projects - it's still got the reference to SuperGrid.OCX, but because the class ID recorded in myprogram.vbp is different from the class ID in the recently recompiled SuperGrid.OCX, it is (quite rightly) not recognizing it as the same file.
The problem is certainly in the compile, when it's assigning it a new class ID - not in the other project where it's using it, and failing upon loading.
================================================
I hope this makes sense - I hope I've described the problem clearly. I'm thinking of writing a quick program which will scan all the files in my project for references to the old class ID and just insert the new class ID, but really, this is a last resort and I'd prefer a proper solution.
Does anyone know about this? Has anyone else had the same problem? How do I get around this?
Thanks for your time, and thanks for reading through all this.
-Sleepy
I have an ActiveX Control which I wrote and maintain in VB6 - it compiles to a OCX file which I can include in the components screen in other programs. (I'll call it SuperGrid.OCX, containing a UserControl called SuperGrid)
OK. Here's the visible problem: If I need to make a change to the ActiveX control, I open up the VB project for it, make my change, and compile again to the OCX file. Then, after that, when I try to open another VB project which includes this OCX file in the components window, I get the message:
Code:
"C:\SuperGrid.OCX" could not be loaded -- Continue Loading Project?Clicking yes brings up many error messages like:
Code:
Errors during load. Refer to frm***.log for detailsIt gives that error message for each form that uses SuperGrid. I found I can get it up and running again by clicking through each of the error messages, then going into Components and ticking SuperGrid again, and then going into each form that used SuperGrid and inserting the control again. But with 15 screens using it, I'll have to do this each time I make a change and recompile SuperGrid. Kinda... annoying.
====Now for the technical garb.====
I've done some digging around. I'm not 100% clued up on ActiveX, and object IDs and versions and things, but, here's what I've found:
In the myprogram.vbp file, it contains a reference to SuperGrid along the lines of:
Code:
Object={3848C8C9-D789-3A77-3838-93F101A9ACB6}#3.0#0; SuperGrid.ocxThe first series of number appears to be the unique class ID, the after that we have #3.0#, which appears to be the version number, and after that I'm not sure what that number is.
NOW, I created a seperate dummy activeX control to try and diagnose what the problem was. I could recompile it to Dummy.OCX, open up a seperate project which included Dummy.OCX, and the class ID recorded in the dummyproject.vbp file wouldn't change. (The version number changed, which VB mentioned when it loaded up, but the class ID never changed, no matter how many times I recompiled). That is correct - the class ID shouldn't change.
But, I performed exactly the same test with my SuperGrid, and I found that when I recompiled it, (drum roll.....) THE CLASS ID HAD CHANGED!!!!!
Summary in techo terms: Each time VB recompiles my SuperGrid.OCX, it is assigning it a new class ID, which is disrupting references to it in other projects.
This is bad, this is wrong, this is a NO NO. This is what is making VB fail to recognize it in other projects - it's still got the reference to SuperGrid.OCX, but because the class ID recorded in myprogram.vbp is different from the class ID in the recently recompiled SuperGrid.OCX, it is (quite rightly) not recognizing it as the same file.
The problem is certainly in the compile, when it's assigning it a new class ID - not in the other project where it's using it, and failing upon loading.
================================================
I hope this makes sense - I hope I've described the problem clearly. I'm thinking of writing a quick program which will scan all the files in my project for references to the old class ID and just insert the new class ID, but really, this is a last resort and I'd prefer a proper solution.
Does anyone know about this? Has anyone else had the same problem? How do I get around this?
Thanks for your time, and thanks for reading through all this.
-Sleepy
