Windows API functions are (mostly) C++ functions that you can call directly from VBA via the
Here's an example you may have seen before:
Public Declare PtrSafe Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
The original function was written in C++. Thus, the online help for the above Sleep function is not especially helpful for VBA developers. The function's definition is shown in C++:
void Sleep( [in] DWORD dwMilliseconds );
We mere VBA developers need some way to translate the second sample into the first sample. Let's look at three options that help us do that.
For years, my go-to resource for API declarations in VBA has been the AllAPI website.
Here in 2023, that's still true even though the website hasn't been updated in over 20 years:
But unfortunately, everything must come to an end; today, it's time for AllAPI.net to end.
So, what's going to happen to the site? Well, we're going to keep it online for the foreseeable future. By the time this site goes offline, Visual Basic 5/6 and the Win32 API functions will probably be ancient technology. And when it does, we'll definitely give an advance warning.
Thank you for visiting AllAPI.net.
Coverage - 940 Declares
The website boasts "940 API-functions, all explained and illustrated with one or more examples."
GOOD: Sample Usage
The big advantage the AllAPI website has over the other two options listed here is its extensive library of sample code where you can see the API calls in use. At the bottom of each API procedure's page is an "Examples" section with links to sample code and a "Related Functions" section with links to related API calls.
BAD: A Lack of 64-Bit Support
VB5 and VB6 do not have 64-bit language support. VBA did not get 64-bit support until the introduction of VBA7 in Office 2010. Since AllAPI.net stopped being updated in 2002, none of its functions can be used as is in 64-bit VBA.
If all you need to know is how to declare a Windows API function that will run in all currently supported versions of Office, look no further than the Win32API_PtrSafe text file.
The file–available for download from Microsoft at the link above–is a 677 KB text file with API declarations, constants, and types. The file provides zero context or hints about why you might want to use one function vs. another. There are a few comments sprinkled into the text file, mostly explanatory text for certain Const values.
The biggest problem I used to run into with this file is just remembering where I saved it. Now I just search Everything for
PtrSafe and it finds it for me instantly:
Coverage - 1,555 Declares
A search for the words "Declare PtrSafe" in the file returned 1,555 hits.
GOOD: Signal vs. Noise Ratio
There is zero fluff in this file. It's simply 16,000 lines of [Ctrl] + [F]-searchable goodness.
BAD: Zero Context
There's no sample code, no cross references, and no clear organization of the contents. Closely related procedures generally appear near each other, but otherwise it's a crapshoot.
This is not a file you browse.
You open it. Search it. Select and copy what you need. Close it. That's it.
Peter Cole's MS Access Windows API Viewer
I have a feeling that my new go-to source for Windows API declarations will be Peter Cole's API Viewer:
Peter's API viewer has a handy built-in search feature.
In the screenshot below, I entered
Gdip* and it found 20 matches for GDI+ Windows API functions:
Downloading the API Viewer
To get a copy of Peter's tool, visit his Access32to64 page. Click either of the big blue buttons that say [Download our FREE AccessAPIScanner and Viewer]. The link will take you to a purchase page, but there is currently a 100% discount so the tool is free (you do not need to enter any payment information).
Coverage - 1,635 Functions (and counting)
Peter's API viewer already has the broadest coverage of the three options shown here.
What's most exciting about his approach, though, is that he built in a reporting tool to his companion API scanner tool. It allows developers who use his free API scanner tool to easily report back to Peter any API declares that are not in his library. As he receives these reports and validates the required API calls, his library will continue to grow.
Beyond that, Peter has scanned the most common DLL's and has a collection of around 10,000 (!) function names. He is working on a process to automate the creation of VBA equivalent declarations through some combination of parsing the .h (header) files and/or scraping the learn.microsoft.com website.
GOOD: Most Up-to-Date and Best Coverage
The AllAPI website has not been updated in over 20 years.
The Win32API_PtrSafe text file has not been updated in over 10 years.
Peter is actively updating his API viewer, including fixes to a handful of mistakes he found in the Win32API_PtrSafe text file.
BAD: Still Rough Around the Edges
The tool has only been available for a few weeks. He's still refining the user interface. That said, the most important part–the API declaration information–is there and (from what I have seen) is correct.