> In Excel 2016 for Mac, the .scpt file must be in ~/Library/Application Scripts/[bundle id]/.
Is this really the case? I thought that was only the case if the AppleScript was being called from within (say) Excel VBA.
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
I have a script that opens an Excel spreadsheet and loops through theCell. The character count for the first cell is 17 (theChrCount) and the contents of the cell (theCellValue) is "Application Files". When I run the script through the first loop, character 1 shows as "A". When I run through the second loop, character 2 shows "pl". The third shows character 3 as "lic" and so on. So the 6th character shows 6 values. Any idea why character 2 would show "pl" instead of "p"? It's like character n is the character at n for n places. This script ran well under the old version of Excel but stopped working on Microsoft Excel for Mac Version 15.33.
set theCell to cell ("F" & i)
set theCellValue to value of theCell as string
set theChrCount to (get count of characters in theCellValue)
repeat with n from 1 to theChrCount --> 0.79s
set theChr to character n of theCell
set theChrProp to properties of theChr
set theFontObject to font object of theChrProp
end repeat
Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.
> In Excel 2016 for Mac, the .scpt file must be in ~/Library/Application Scripts/[bundle id]/.
Is this really the case? I thought that was only the case if the AppleScript was being called from within (say) Excel VBA.
BTW I was able to reproduce this. I couldn't test on an earlier version of Mac Office 2016 but it is definitely different behaviour from Excel 2011. So I would agree that it is an error (bug).
Office 2016 is sandboxed to comply with Apple's demands.
Sandboxing is a simple concept:
About App Sandbox - Apple Developer
It's amazing how complicated and expensive it is to comply with.
Thanks, Jim.
However, the reason for my question was not that I didn't understand what sandboxing is about. It's that my understanding was that Sandboxing prevented applications from running scripts that automated other apps, unless they went through the kind of mechanism now in place for Office 2016 (i.e. via ApplescriptTask) but did not prevent Applescripts from automating Sandboxed apps, regardless of where the .scpt or AppleScript .app was located. Since I was able to test the script the OP posted without putting it in the relevant
~/Library/Application Scripts/[bundle id]/
folder, I found James's remark a bit worrying. Did he mean that (for example) an Applescript placed elsewhere could not do things such as get Excel to create files in its sandbox? Or did he mean that Applescripts placed elsewhere might run, but would not necessarily behave properly, potentially resulting in erros such as the one the OP describes? That would be very strange. Or what?
FWIW I also put a copy of my test code in the appropriate Application Scripts folder, and the same problem occurred. It does not occur with Excel 2011, so I have to conclude that there is an error (bug) in there somewhere. Unless someone is able to tell me why I wrong!
Thanks, Jim.
However, the reason for my question was not that I didn't understand what sandboxing is about. It's that my understanding was that Sandboxing prevented applications from running scripts that automated other apps, unless they went through the kind of mechanism now in place for Office 2016 (i.e. via ApplescriptTask) but did not prevent Applescripts from automating Sandboxed apps, regardless of where the .scpt or AppleScript .app was located. Since I was able to test the script the OP posted without putting it in the relevant
~/Library/Application Scripts/[bundle id]/
folder, I found James's remark a bit worrying. Did he mean that (for example) an Applescript placed elsewhere could not do things such as get Excel to create files in its sandbox? Or did he mean that Applescripts placed elsewhere might run, but would not necessarily behave properly, potentially resulting in erros such as the one the OP describes? That would be very strange. Or what?
FWIW I also put a copy of my test code in the appropriate Application Scripts folder, and the same problem occurred. It does not occur with Excel 2011, so at the moment I have to conclude that there is an error (bug) in the Excel Applescript implementation somewhere.