More DECLARE DLL performance discussion

In this post DECLARE DLL performance questions I asked whether using the WIN32API keyword or the particular DLL file name would be faster. It turns out that Win32API is much faster, and Martin Jindra, Timo, and Fabio Lunardon answered correctly that with Win32API, VFP doesn’t have to deal with files at all, but rather just DLLs that are already loaded.


Instead of dealing with files, DECLARE DLL for a Win32API calls the much faster GetModuleHandle to find the handle for the already loaded DLL.


Fabio goes on to ask whether the “A” feature can be restricted to Win32API calls. However, this is very difficult, because the DLLs that comprise the Win32API are not constant from Windows version to Windows version. For example, the VFP GETDIR() function calls the  SHBrowseForFolder  API, which is implemented in Shell32.dll.


GETDIR("c:\Windows","Description","Window Caption",64)


The AddUrlToFavorites function is found in shdocvw.dll. The GDIPlus Win32API functions are found in GDIPlus.dll Also, not every Win32API DLL is loaded in every process.


Comments (4)

  1. RyanNerd says:

    Thanks Calvin for this very useful info.

    I used to take the time and research what DLL a system function was in so that I could "improve the performance" by directly referencing it in my DECLARE statements.

    Stupid me (I’m wiser now thanks to you).


  2. Fabio Lunardon says:

    With requirements OS,

    can you calls GetModuleHandleEx for other dlls ?

    Can you implement a SET/SYS() for disable the "A" feature ?

  3. I received a comment on this post: Will GetLastError ever work properly in VFP8.0?.  I was consistently…

Skip to main content