VB Macros for Office 2016 for Mac require Permissions every time they try to access a file! Is there any way to get around this behavior? - excel

Question

Any VB Macro in Office 2016 shows a dialog box to the user asking for permission, every time the Macro tries to access a file! Is there a way to avoid it.

Answer 1

Unlike VB Macros in Office for Mac 2011, VB Macros in Office 2016 for Mac do not have access to external files by default. The Office 2016 for Mac apps are sandboxed and hence they lack the required permissions to access external files. Existing macro file commands are changed to prompt the user for file access if the app doesn’t already have access to it. This means that macros that access external files cannot run unattended; they will require user interaction to approve file access the first time each file is referenced.
Developers should use the GrantAccessToMultipleFiles command (see following section) to avoid this experience. This command lets your app get permission for all the files at one time, thereby avoiding a difficult user experience.
GrantAccessToMultipleFiles
This lets you input an array of file paths and prompt the user for permission to access them.
Boolean GrantAccessToMultipleFiles(fileArray)
Parameters
fileArray -- An array of POSIX file paths.
Return Values
True - The user grants permission to the files.
False - The user denies permission to the files.
Note: Once granted, the permissions are stored with the app and user need not grant permission to the file anymore.
Example: 
 
Sub requestFileAccess() 
 
'Declare Variables 
    Dim fileAccessGranted As Boolean 
    Dim filePermissionCandidates
 
 'Create an array with file paths for which permissions are needed 
    filePermissionCandidates = Array("/Users/<user>/Desktop/test1.txt", "/Users/<user>/Desktop/test2.txt")
 
'Request Access from User 
    fileAccessGranted = GrantAccessToMultipleFiles(filePermissionCandidates) 'returns true if access granted, false otherwise 
     
 
End Sub

Answer 2

I wanted to delete a file in Excel using VBA's Kill syntax and got the permission prompt when the VBA attempted to execute the command. My script is supposed to run once every 3 minutes day and night so responding to separate prompts wouldn't cut it.
To workaround the issue, I created a wrapper for VBA's Kill function called myKill. To implement it I:
Globally replaced all calls to Kill with myKill in my VBA code.
Added a new VBA subroutine called myKill (code below)
Created an AppleScript file to actually remove the file (code below)
Granted Excel Full Disk access in System Preferences/Security & Privacy/Privacy. Not sure this step was necessary but I mention it as it's my current configuration. It's worthless without the first three steps.
Here is the myKill subroutine:
Sub myKill(fname As String)
Dim s As String
If Left(Application.OperatingSystem, 3) = "Mac" Then
s = AppleScriptTask("Kill.applescript", "Kill", fname)
Else
Kill fname
End If
End Sub
Here is the Kill.applescript file contents:
on Kill(fileName)
# implementation of vba kill command on Mac. Mac sandboxes Microsoft's
# kill command
tell application "System Events" to delete alias fileName
end Kill
The Kill.applescript file must be stored in
/Users/your user name/Library/Application Scripts/com.microsoft.excel/Kill.applescript
The first time the Apple Script executes, Mac OS will ask for permission for Excel to manipulate files in the directory where the file to be deleted is located. Once given, future file deletes in the directory won't trigger the permission request. I tested that by exiting Excel, reentering and deleting another file.
RANT
How anyone thought making programmers jump through all these hoops or click "OK" each time a file had to be deleted was an acceptable implementation is beyond me. Because someone in Microsoft dropped the ball on abstracting simple file manipulations like Kill over 10,000 programmers have seen this web page trying to figure out what they have to do to delete a file in Microsoft Excel.
Yo Microsoft VBA Project Manager! I'm talking to you! Your job exists because Joel Spolsky convinced Bill Gates that a macro language for Excel was a good idea despite Gates' doubts. Your job is to ensure that Excel VBA abstracts os weirdness so programmers can get their job done and not have to hack in another language.