>Hi George,
>
>Thanks for the quick reply. I'll give it a try.
>
>I saw in the win32api FAQ at the UT that you mention looking at the win32api help file that comes with vfp 3.0 for information on win32api functions. I still maintain 3.0 applications and still have that help file. I tried some of the links mentioned in the faq for more up-to-date info on win32api, but didn't have much success. Is the old file from VFp 3.0 still accurate enough.

It's generally accurate but incomplete. Many of the API calls documented in it have additional options that didn't exist at the time the file was generated. The best source of information is the MSDN reference documentation, available by subscription from Microsoft; it's updated at least quarterly.

Since it contains not only Platform SDK information, but all the supported API families on all the MS operating systems, and also contains whitepapers, documentation on the other (non VFP) programming lanuguages, MS Office, and a good deal more, it's probably one of theose things like The hacker's Guide to VFP 6.0 that you really should invest in if you plan to do serious development. The vast majority of the information is available on-line through the MSDN OnLine service, but having it at your fingertips along with all the sample code is simply too valuable to ignore. So spend some money and get a subscription.

>
>Also, I was reading the the VFP 5.0 manual that a call to win32api looks for the function in kernel32.dll, gdi32.dll, user32.dll, mpr.dll, and advapi32.dll. Do you know if these files are automatically installed with win95 and nt workstations?
>

These libraries or their equivalent are available cross-platform in the Win32 environment. The biggest advantage to using the WIN32API catchall designator is that you don't have to test which operating system is running for common API calls, the WIN32API designator searches through the appropriate .DLLs to see what's acting as the provider for the call, rather than specifying the exact provider by name (for example, many of the network-related API calls are provided by different .DLLs under different operating systems; using the WIN32API designator picks the right one without having to code the DECLARE...DLL statement differently within a CASE statement to handle platform differences.

IOW, some of them are present on all platforms, and together, their functionality is provided cross-platform by the set of DLLs searched by the WIN32API designator. There are drawbacks (if you haven't declared GetLastError(), for example, and you declare it using the WIN32API designator, you'll lose the error code you want to examine with it - the solution is to declare it ahead of time so that it's available before you need it, and take some care not to hide it by having a UDF with the same name as your declaration assigns.


>Thanks again for your help.
>
>Paul
>
>
>
>>Hi Paul,
>>
>>Thanks for the kind words.
>>
>>To activate another application and its window use the following:

>>DELCARE SHORT SetForegroundWindow IN Win32API;
>>  INTEGER hWnd
>>* lnhWnd is the Window handle of the application to activate
>>llresult = (SetForegroundWindow(lnhWnd) # 0)
>>IF llresult
>>  * The app was activated.
>>ENDIF

>>The value returned by Is_Run32 can be passed to SetForegroundWindow.