I've had this same problem. The product was a distributable
application, and I didn't want one of the installation steps to be
registering a ocx file. I found that LabVIEW application builder will
use whatever version of the 3D graph control is installed in the
system. This means that if both LabVIEW 7.1 and LabVIEW 7.0 are
installed and an application is built with LabVIEW 7.0, the VI will be
using the 3D ActiveX graph control that LabVIEW 7.1 uses. Then, when a
different computer gets the LabVIEW 7.0 run time installed, the
application will complain about the wrong cw3dgraph version. This may be fixed by doing the following on the development computer:
Rename the "cw3dgraph.ocx" (from LabVIEW 7.1) in the Windows/System32 directory to something else.
Copy the
"cw3dgraph.ocx" file from the LabVIEW 7.0 installation before building
the application to Windows/System32.
Build the applicaiton in LabVIEW 7.0.
With these steps the application will work fine with the ocx file that gets installed from the LabVIEW 7.0 run time engine.
Note that this applies with LabVIEW 8.0 vs. LabVIEW 7.1 as well. Still a big pain, but at least the pain can be moved to
the development instead of distribution.
I've added what I think are the ocx files from LabVIEW 7 and LabVIEW 8, in case it is helpful, but I provide no warranty.