quote:
Originally posted by Choli
Thanks for the suggestion, Cookie. But do I need to change my COMCTL32.OCX every time I want to compile the program? That would be a bit dodgy... I thinking... would it be possible to have 2 versions of that file installed (registered) at the same time? What about if I copy the old comctl32 with other name and use it in VB instead of the new version? (i mean in the menu Project > components).
The reason why compiling with an older version has the benefit of working with newer versions is because of the binary compatibility and because of the same GUID and ProgID's (if there wasn't binary compatibility the GUID and ProgID's would be different). So no, you can't have two copies of that same OCX registered at the same time; they use the same GUID and thus there can only be one path to the OCX file (the currently registered one).
Note: this also goes for all GUID's, not only for GUID's of OCX's. Hence why installing, for example, multiple msn messenger versions is not _that_ good.
This said, you can run an application with another OCX by putting that OCX inside its applications directory or startup directory _and_ IF that application handles this correctly (not all use the default windows path search order and certainly not all handle the registering of such files correctly). It also depends on weither the OCX is selfregistering or not. If the application registers the OCX in its current directory or the OCX registers itself because it was called wrongly by the application, the shit could hit the fan. Especially when you decide to delete that OCX again (eg: you uninstall the application). Hence this is a _very_ common cause to problems with DLL's, OCX's, etc that needs registering.
I actually didn't tried yet what you suggested though; it might work, it might not. It depends on how VB handles that GUID and filename inside the project file. I do know that if there is an older version listed there (eg '#1.2#') and you have a new version registered (eg: typelibrary v1.3) that it will automatically update to that new one (despite disabling the setting "Upgrade ActiveX Controls" in your projects properties as that is something different). So I assume for now that VB follows that GUID and updates its project file with the currently registered typelibrary.
I'll try some stuff out and let you know... In the meantime you could make a small batch script or something which switches between the old and new by renaming and (un)registering them (that's what I do atm). Besides, there is no harm in using the old OCX (if you know what you're doing; as in: you know you are running on an old one), as long as you don't notice any crashes of course and as long as a certain program doesn't explicitly requires the new version
EDIT, after trying several things: As I suspected, VB looks at the GUID and follows it to get the current registered version and it will compile with that one. So putting:
"
Object={6B7E6392-850A-101B-AFC0-4210102A8DA7}#1.2#0; C:\MyApp\COMCTL32.OCX" inside your project file or form files will not work. Thus I'm afraid you'll need to 'swap' the versions each time before you compile (a batch script is very handy for this; pm me if you need it
).
Plus! Tweak! for Plus! 3.61 :)
/ 
You're right.
