MelissaEvans
asked on
OCX Compatibility
I built a complex OCX that I needed to use in a shell I made, and also give to another devloper to use in his shell. The many peices of my OCX made it difficult to give him the whole thing, so I "stubbed it out." I gave him an OCX that has all the public properties and methods, but no code. He compiled it into his shell, and now I neeed to put the real OCX in. I get the error:
"Failed to load <control> from <ocx>. Your version of <ocx> may be outdated. Make sure you are using the version of the control provided with your application."
On my OCX development computer, I have cleaned the registry of all references to the OCX. I then copied the stub that I mailed to the other developer and registered it. In the project, I had the compatibility pointing to the stub. I am using Binary Compatibility. I was under the assumption that by having the compatibility version be the stub, it will allow me to "upgrade" without problem, but I still get the error. I'm hoping I'm just missing something stupid and that one of you geniuses will be able to help. =)
~Melissa
"Failed to load <control> from <ocx>. Your version of <ocx> may be outdated. Make sure you are using the version of the control provided with your application."
On my OCX development computer, I have cleaned the registry of all references to the OCX. I then copied the stub that I mailed to the other developer and registered it. In the project, I had the compatibility pointing to the stub. I am using Binary Compatibility. I was under the assumption that by having the compatibility version be the stub, it will allow me to "upgrade" without problem, but I still get the error. I'm hoping I'm just missing something stupid and that one of you geniuses will be able to help. =)
~Melissa
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>> I put the compatibility OCX where the new one will be compiled to
This is the problem. You must NOT point the compatibility OCX/DLL to the same path you compile to. You have to make a copy of it.
This is because of the order (I think) in which VB does it's compile, which I think (from observation) is:
1. Delete the old DLL/OCX/whatever
2. Get the old vtable stuff
3. Compile the new DLL/OCX/whatever
So, if you are pointing at the same location (for compatibility) as you are compiling to, you will not be binary compatible. To solve the problem, create a /compat directory somewhere, and copy your OCX into it. Then point your compatibility path to the version on the /compat directory.
When you are in-between "real" releases, dont update the version in /compat, but each time you make a real release (where you want to maintain backward compatibility), update the /compat version.
This is the problem. You must NOT point the compatibility OCX/DLL to the same path you compile to. You have to make a copy of it.
This is because of the order (I think) in which VB does it's compile, which I think (from observation) is:
1. Delete the old DLL/OCX/whatever
2. Get the old vtable stuff
3. Compile the new DLL/OCX/whatever
So, if you are pointing at the same location (for compatibility) as you are compiling to, you will not be binary compatible. To solve the problem, create a /compat directory somewhere, and copy your OCX into it. Then point your compatibility path to the version on the /compat directory.
When you are in-between "real" releases, dont update the version in /compat, but each time you make a real release (where you want to maintain backward compatibility), update the /compat version.
And, just in case I'm misinterpreting what you are saying, if you have make a copy of the OCX with a different name, but in the same directory, I would recommend what I posted above, but with the same filename (but different directory) - just in case VB has a hard time understanding a different filename.
And, just in case I'm misinterpreting what you are saying, if you have make a copy of the OCX with a different name, but in the same directory, I would recommend what I posted above, but with the same filename (but different directory) - just in case VB has a hard time understanding a different filename.
ASKER
It ended up being a licensing issue, but thank you for your time. =)
No problems. I found a good link that explains versioning quite well the other day, if you are interested:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dn_voices_webservice/html/service08152001.asp?frame=true
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dn_voices_webservice/html/service08152001.asp?frame=true
ASKER
~Melissa