>>>>Yes. All you are doing is declaring a DLL function. This is supported under any version of VFP. You will need to have the OCX and all of its support files on the local PC. You can use the VS utility Depends.Exe to determine what files are needed for the OCX to work. You can also get this information from the dependency file. It is usually named the same as the OCX but with DEP extension. It will list the files needed for the OCX to work. For example, Comctl32.OCX needs the following:
>
>Larry,
>
>Sorry for redirecting on old thread - but I figured you would know the answer to this. Does re-running

regsvr32 myocx.ocx

multiple times harm anything? Does it just "replace" the old enty or create another one, causing potential conflicts?
>

In general,it doesn't harm things, although it may create problems if someone else installs a later version of the control, since the last registered version is assigned the VersionIndependent ProgID if one is in use, or if registration sets an initial registry value that gets updated in the course of using the OCX. You can do the same thing via the API - see Paul Tatavu's FAQ entry on triggering self-registration code without the need to call REGSVR32.

>Also - can we leave the OCX in our app's directory or does it need to be down in the system?
>

It can be in any local directory - if referenced by ProgID or CLSID, it looks in the registry to find the component. If non-registered DLLs are referenced, they will need to belocated somewhere in the Windows search path, since there's no pointer to them via the registry. This generally means that they either need to live in one of the Windows system directories, or in the directory tha the app is run in, or in an additional folder specified in the Windows path environment setting.