Double-declaring APIs

Access MVP Jack Stockton wrote in with an idea for a post (shared with permission):

Is it time to stop double declaring APIs?

Example:
#If VBA7 Then
   Private Declare PtrSafe Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
#Else
   Private Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
#End If

There is no longer any supported version of Access that is not VBA7 aware, thus the declaration for not being VBA7 is very unlikely to be used.  The problem if you were to not do the double declaration and only did the non-VBA7 line (old code), you will end up with an application deployed that blows up on the user when 64bit Office gets deployed.  This is happening more often now that 64bit Office is the default install.  Users/IT staff have to know this and change to 32bit install.

For many apps developed in the past, 32bit Office was a requirement because so many external APIs to Office were only in 32bit.  It is starting to be the other way now in that a 32bit API may not be available.

My Initial Response

That's a good question.  

I absolutely would not ship code that was 32-bit only in 2021.  As for removing the extra declare to support Access 2010 and earlier, I don't know how I feel about that.

Since it's a conditional compilation line, it won't have any performance effect (other than a negligible increase in the size of the code). Additionally, I have pretty strong feelings about backward compatibility.  That said, there is a signal vs. noise argument to be made for removing the unused declare if you know that none of your users is running Access 2007 or earlier (as you said, those versions are unsupported).

I guess I'm personally inclined to leave the double declares in place for the foreseeable future.

Upon Further Consideration

I think it comes down to how much control you have over your deployment environment.

If you know for a fact that all of your end users will be running Access 2010 or later, then you can safely do away with the extra declare.  And there are a lot of Access developers that fit into that camp.

However, there are some specific situations where I recommend leaving the extra declare in place:

1. Legacy environments: hopefully these are rare, but if you work in an environment where you know there are end users running Access 2007 or earlier AND those editions of Access cannot be updated for some reason, then you will need to leave the extra declare in place;
2. Code Library routines: these are the routines that you use in multiple projects; whether you store them as exported text files or a single Access database, you can never know for sure whether the next project you use them in may need to support users with older versions of Access; and
3. Code you share with others: this is the category that this blog falls under; I plan on leaving the extra declare in place for as long as I think there may be readers deploying the code into those older environments.

Referenced Articles

Office 2019 Runs in 64-bit Mode By Default. Here’s What That Means for VBA Developers

Through Office 2016, default installs used the 32-bit version of the software. Now that 64-bit is the default, it’s time to bite the bullet and convert your VBA code.

No Longer SetMike Wolfe

Reverence for Backwards Compatibility

A feature that was heavily used by a very small percentage of power users has been maintained over the course of five subsequent upgrades (and counting). Now that is showing reverence to backwards compatibility.

No Longer SetMike Wolfe

Signal vs. Noise

My approach to software development in four words: Less noise. More signal.

No Longer SetMike Wolfe

Building Your Library

Thirteen years ago, I chose to maintain a folder of text files rather than a single Access database library. I’ve never once regretted that decision.

No Longer SetMike Wolfe

Image by Pitsch from Pixabay

CORRECTION [2021-10-10]: Thanks to reader Colin Riddington for pointing out that VBA7–and its 64-bit support–first appeared in Access 2010, not Access 2007.  I updated the article to reflect this correction.

CORRECTION [2021-10-11]: Tip of the hat to Colin for pointing out that I missed another spot where I was referring to the wrong version of Access.  The now-corrected text, "... none of your users is running Access 2007 or earlier...", previously read Access 2010.