If I manually grant access to a file, my code is able to open the document in subsequent runs. I will be working with new files each day so I would like to eliminate the grant access pop up window. I've tried sudo python myscript.py, but it doesn't resolve the issue.
While the open() function is able to open the file, I want to be able to use the range style referencing available in xlwings.
Will you please tell me how to grant Python (or just my script), not only to the individual files that are currently in the folder but also any files which get added to a folder in the future?
The issue you're seeing has nothing to do with Python or xlwings, but is really a "feature" of Excel 2016 on Mac: It is sandboxed and thus cannot access files outside of the app's directory, see this answer and this tutorial.
To revive this thread for Office 365 and Catalina: it is still necessary to save Excel files here:
~/Library/Containers/com.microsoft.Excel/Data
to avoid the prompt for granting access.
or to this folder generally for Office files:
~/Library/Group\ Containers/UBF8T346G9.Office
Related
I am attempting to deploy a custom MS Excel add-in across our network environment following this article: https://www.excelguru.ca/content.php?152-Deploying-Add-ins-in-a-Network-Environment.
One users computer is causing trouble for me. I install as directed, specifically when asked, I say "NO" to copying the file to the local user's folder. Initially the add-in appears to have installed and work properly. However, upon restarting Excel, I find that in fact, Excel gives the error message stating the add-in is missing and has a file path to the local users folder. I have tried multiple times to the same outcome.
On other users PC's (win7 and win10 boxes) the file installs fine from the network and remains after a restart of Excel. So far, the issue appears to be isolated to one user's PC. He is on windows 10 and excel 2016.
Has anyone encountered this? To me seems like a bug maybe?
I've seen that happen if the user initially selects to copy it locally, then removes it, and then tries to add the network copy. The only fix is to edit the registry to remove the local reference, and then add the network copy again.
It's important for the end users to not copy the file locally the first time, or you end up in this mess.
Search their registry for the filename of the add-in and delete it.
I'm struggling on how to open MS Access Runtime using VBA, from an Excel file.
You can open the full version of Access using CreateObject("Access.Application"), but that doesn't open Access in Runtime.
We only have Microsoft Access Runtime installed in some computers, because that's all we need to use the front-ends we've developed. So we need to open the accdb files using MS Access Runtime, but from Excel.
Any help is appreciated, thank you
You can use the Shell to open a file, as if you typed that command into window's command prompt.
d = Shell("pathToFile\Database1.accdb /runtime", vbNormalFocus)
Another option you could use to open in the file in runtime (if someone opens it from the folder or through some other method without the /runtime switch) would be to change the file extension to .accdr. This will always force runtime.
This is a long shot, but does any one know how to remove the lock file created by access 2013 file type ".laccdb".
I have an excel sheet which is connected to the access database via power query. The access database is on a shared drive. However even when this file is closed the locking file for the access database is not deleted.
When trying to remove the lock file it just says that unable to close as another program is using.
I've closed down the machine, removed all temp files, checked nothing is running and also checked in computer management within the administration tools. and checked for any open files.
I know the database should be split to stop this happening. however this is not my database, and the user refuses to split.
Any help will be grateful.
You can open and read the lock file with a text editor (I use Notepad++); within the file you should find the computer name (or some similar identifier) of the one(s) who have it open. You could then take that name/number/whatever to IT and see if they can identify who the user is. You should be able to close it from their computer. Hope this helps.
I have an add-in in Excel that needs to store some data in the HKEY_LOCAL_MACHINE registry. because of the UAC control in Windows Vista and earlier versions, I added a manifest file. But it is just not working. I even added the manifests in each of the projects of my solution. I have 5 projects in my solution (3 VB projects, 1 c++ and 1 deployment).
I am using VS2005. I added the manifest file to the project (with the requestedExecutionLevel set to "requireAdministrator" and embedded the manifest using mt.exe in a post-build command.
Even with that, I am still getting an access denied to the HKEY_LOCAL_MACHINE. The only thing that is working is when I start Excel as "Run as administrator".
Any clue what the problem might be? Thanks.
Manifests in DLL do not affect the execution level of the application, in this case it's excel.exe.
Here are the options you have:
to run Excel as administrator;
to modify the add-on to write to HKCU rather than HKLM.
If you need to store data available to other users, consider using ProgramData folder (CSIDL_COMMON_APPDATA or FOLDERID_ProgramData). Then your add-on creates a subdirectory inside ProgramData and modifies its permission so that this new directory is writable by anyone (by default, only the user account that created the folder has write permissions, other users can only read).
There are some other options:
You can write a service that your add-on will communicate to write data into HKLM but it's not.
You can create an elevated COM object which will write the data into HKLM.
Although users don't expect Excel to require elevation when run, therefore consider changing your logic so that your add-on does not require elevation at all.
Since 2005, when Microsoft prevented HtmlHelp functioning off a network share, e.g.:
\\appserver\tos\PointScanner.exe
\\appserver\tos\PointScanner.chm
What are we supposed to do instead?
(Given that the application is not installed locally.)
To rephrase: What is Microsoft's intended, supported, out-of-the-box, help solution?
You can allow access via the Registry setting described here:
http://support.microsoft.com/kb/896054/
If you don't want to open any security vulnerabilities by modifying Registry settings your application could also create a local copy of the .chm file, e.g. in the users temp folder (%TMP%) and open the help from there. You can remove the file again when your application exits (in case you don't want to leave anything behind on the user's workstation)
I started with the registry change mentioned by divo. Eventually I moved from network folder based chm files to actual "html help". This was easy for me since I use RoboHelp which can generate either format from the same source code.