Handle OCX versions between OS's ???

I've written some apps on my WIN2K machine.

When I install them on my XP machine, I notice that some original XP OCXs get replaced with the ones from my installer and WIN2K.

For example, the mscomctl.ocx on WIN2K is a different version than the one on XP.

1) Does this cause problems for other software already on XP?

2) The OCX that ships with XP is newer than mine on 2K, and causes a run-time error with my app (an Imagelist problem) - How do I fix this?

3) How can I be sure that the OCX I ship with my app is compatible with other OSs ?

4) How can I be sure that the OCX on another OS is compatible with my app ?

Thanks!

Don't place them in the system folder. Leave them in the same folder as your application, and they won't have any interferance with the newer versions., and still be available to your application.


Phreak

What's to keep my app from using the OCX that already existed on the system?

Will it *always* look in the local dir first?

Also, it seems like this would mean that I couldn't use MergeModules anymore?

I'm not exactly sure how VB handles these things. It would seem likely to look in the system folder first, since thats where it expects them to be. I think its just a bit of trial and error.


Phreak

In theory, the newer version OCX should work on all versions of the OS. However, I have found a problem with the RichTextEdit control on XP. MS knows about it but they only recommend installing SP2 when it comes out - you may have to do the same. As an interim fix, you may have to manually copy versions for differing OS's which I admit is messy. Short of testing on all versions of the OS, it is difficult to know whether an app will work on it. Sorry I can't be more helpful.

PHREAK - Trial and error could take forever to figure out! There are potentially dozens of OCXs - I've written 14 apps myself and use many of them....


Nikcjc67 - The newer version of the OCX should work, but my question is - how do I handle this when I build my app and the installer?
Do I attempt to put the new OCXs from XP on my 2K box (that seems rather dangerous) ?

I can't build an installer without the OCXs 'cause I'll neer know which ones the target system has/doesn't have....

How are other people handling this problem???

Quote:

---

Originally posted by «°°phReAk°°»
Don't place them in the system folder. Leave them in the same folder as your application, and they won't have any interferance with the newer versions., and still be available to your application.


Phreak

---

Ummmm that's not even close to being right. It will attempt to load the OCX from what ever location it is registered at. OR last registered at. The newer one should have been compatible with the older one. You didn't specify what installer you are using, but there should be an option setting somewhere to not install the OCX if a newer one is found.

TG

I'm using InstallShield Express v4.

Setting ISE to leave the newer file may be part of the issue I'm asking about.

The newer OCX is giving me grief - complaining about not being able to load the ImageList from the (newer) OCX (mscomctl.ocx)

So, how do I avoid this without putting an older OCX on a newer system?

Well, as long as the OCX/DLL's are in the same folder as the EXE of your application, they work for me. There have also been other people I've seen post this. For example, the Winsock control. If that is in the same folder as my application on someone else's computer, it works fine.


Phreak

So which is it?

If I install (and register) an OCX in the App Dir, isn't that the same as putting it in the SYSTEMDIR ?

I mean, if the app uses the most recently registered version, then ALL apps would use the one I put in the App Dir - right?

So why not install it in the SYSTEM DIR?

As well, if I install an older version (from WIN2K) of an OCX, won't that screw up other apps which require the new one (from XP)?

Quote:

---

Originally posted by wayneh
So which is it?

If I install (and register) an OCX in the App Dir, isn't that the same as putting it in the SYSTEMDIR ?

---

No.

Quote:

---

I mean, if the app uses the most recently registered version, then ALL apps would use the one I put in the App Dir - right?

---

Yes.

Quote:

---

So why not install it in the SYSTEM DIR?

---

Personal preference. If you feel your app can be used by other people in the future, go ahead and place it in the System folder. Microsoft can do that because they know other people will be using it.

Quote:

---

As well, if I install an older version (from WIN2K) of an OCX, won't that screw up other apps which require the new one (from XP)?

---

As long as the developer has been careful while writing the OCX/DLL, there should be no problems. Sometimes, what happens is binary compatibility breaks. Then people get mad. And start tearing their hair out.




PS: Someone please correct me if I've mentioned incorrect information in this post. I'm on decaf. :cry: