>>>What is usually the trouble when a .dll cannot load when calling a function and there was no entry point error in the declaration statement? Using ver.dll...
>>
>>There are a number of possible causes; the most frequent one is that some other resource required by the .DLL is not present/cannot be found. Commonly, this might mean that some shared .DLL is not there, or not current, or that if it is there, that it has not been registered yet.
>>
>>Other things include declaring the wrong number of parameters in the DECLARE, or the right number of parameters, but the parameters are of the wrong type expected by the .DLL.
>
>Thanx Ed,
>
>I'm probably not calling it correctly. Can you see a problem with this? I'm still not clear on API datatypes. Do I need a pointer?
>

The declaration looks correct; it expects to receive a pointer to a string and a pointer to a dword; I don't know what it's doing with the second parameter, but according to the doc it's supposed to receive a zero. The error coming back from VFP isn't terribly helpful, either. it turns out that there's a problem with VFP's .DLL loader and the VER.DLL as far as the .DLL file format (NT is a little more helpful). It doesn't think it's a Win32 .DLL image.

And if you go a step further with it, it's got the signature of a Win16 .DLL! so you won't be able to get at it directly from VFP; you'll need a wrapper function unless FoxTools provides a way to access 16 bit .DLLs.

>pcFileName = "amovie.ocx"
>lndwHandle = 0
>declare integer GetFileVersionInfoSize in ver.dll as getsize;
> string @lptstrFilename, ;
> integer @lpdwHandle
>
>lnInfoSize = getsize(@pcFileName,@lndwHandle)
>
>Is there a document on api types somewhere that is more detailed than help and is there an easy way to find out what shared .dll is required by any given library like ver.dll?