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

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.