"a Win32 API" - you seem to misunderstand that there are many Win32 APIs. There is only one Win32 API. Win32 API is standing for all C functions of Windows DLLs, there surely are more APIs in windows, eg WMI is a different API and there are much more things windows offers as interface to make use of it. Cyril already pointed you towards several definitions of the term API. Win32API is a API, but despite of the different versions of it because of the different windows versions, there is only one Win32 API.
Win32 API is naming all the functions windows offers to any programming language to make use of in their applications. By using foxpro you already use many of the API functions indirectly, eg a foxpro form is a windows form and is created by the os with many Win API functions.
If you like you won't need many of the functions windows offers and can do applications with the foxpro language alone, but there surely are things worth investigating, no question.
The official documentation is from the creator of windows and it's API: Microsoft. It's called the MSDN Library. For example you find Microsofts description of the GetMonitorContrast Function here:
http://msdn.microsoft.com/en-us/library/dd692942(VS.85).aspx In regard of how to know what hMonitor is: In general a function is part of a family of functions of a DLLs of windows. MSDN often does better describe the parameters and their meaning, constants and structues involved etc. For example the meaning of hMonitor is described by both news2news and MSDN:
Handle to a physical monitor. To get the monitor handle, call GetPhysicalMonitorsFromHMO
NITOR or GetPhysicalMonitorsFromIDi
rect3DDevi
ce9.
So this simply is the result of another API function. There are certain naming conventions and nomenclatures, eg a parameter beginning with h typically is a handle, hwnd is a handle of a window. a handle typically is an integer value standing representive for an object instead of an object reference to the object adress in memory.
And from the DELARE perspective the semantics of the command are as the foxpro help says:
DECLARE [cFunctionType] FunctionName IN LibraryName [AS AliasName] [cParamType1 [@] ParamName1, cParamType2 [@] ParamName2, ...]
So you define the type of the function result, then the function name within the DLL and then the list of parameters and their type, and if they are by value or referential parameters.
Yes, there are many things and terms to learn, but you can and should perhaps keep it to a minimum of what you really need additional to what foxpro offers itself. GetMonitorContrast for example has Vista or Win2008 Server as minimum requirement and even though a VFP9 application with the vfp9 runtime can run on win98, me, xp, vista and win7, you limit it on Vista or win7 by making use of that function.
DECLARE is also capable to declare functions from other DLLs not part of Windows, not part of the Win32 API. There are many third party vendors of DLLs, commercial and open source. DECLARE can make use of such DLLs with c functions, in fact it's not important the function is written in C/C++, it can also be a pascal DLL, as long as it's a functional DLL in contrast to a DLL with COM Servers in it or an .NET Assembly DLL.
I surely opened a can of worms now, keep calm and just see the general idea of API is to enable external programs to make use of functions and to extend capabilities of a language or product. You can but not necessarily need to make use of that. DECLARE is one way out of foxpro to include functions from DLLs, CREATEOBJECT(Oleclassname)
is another way to make use of OLE classes, COM Servers in DLLs or OCX files, There are further things like Webservices and many more more to extend foxpro.
Put into one word this is interoperability. Don't complain there is no documentation or reference to it, you could also explain there is no book explaining life. ;)
Bye, Olaf.
