I have an XLA file that is to be deployed to a number of users in the organisation as an Excel add-in. My intention is to deploy it to a directory in the user's "documents and settings" folder in "Application Data\MyCompany". (In fact this is all working through a wrapper that copies the latest version of the XLA locally and installs it as an Excel add-in).
However, if a user creates a sheet that references a function defined in this XLA then Excel appears to store the absolute path of the XLA in the function call. Thus, if the user sends the sheet to a colleague Excel fails to resolve the function as their copy of the XLA resides at a different absolute path (as their username is part of the absolute path).
My belief up until now was the Excel "just coped" with this as long as the XLA was installed as an add-in but this does not appear to be the case.
Is it really the case that I need to enforce an identical absolute path for my add-in for all users? This is possible within a single organisation but I honestly can't believe this is true as it seriously impedes sharing of XLS files.
Thanks.
There's no good way to do this. I put my xla files on a network share rather than locally and install them via the UNC path. That only works for me because everyone has access to the share, which may not be the case for you. Here's some other alternatives
http://www.dailydoseofexcel.com/archives/2008/06/02/fixing-links-to-udfs-in-addins/
I simply remove the path with a sub like this one:
Sub RemoveXlaPath()
'
' Goal: delete the path reference to the add-in, i.e. everything before and including the '!'
' ='C:\Program Files (x86)\Microsoft Office\Office14\LIBRARY\populator.xlam'!famedata(...)
'
Cells.Replace What:="'C:\*xla*'!", Replacement:="", _
LookAt:=xlPart, SearchOrder:=xlByRows, MatchCase:=False, _
SearchFormat:=False, ReplaceFormat:=False
End Sub
Can you specify an environment variable-based path? E.g. %APPDATA%\MyCompany
What I have done is if I give a user a XLS , it has in its on open event some code which - installs the the XLA as part of its on open event. It also uninstalls old version if any (delete and command bars). This self distributes. In theory it could clean up any paths. This assumes there is some shared drive which everyone can access, this prevents them copying the XLA to local drive. Alternatively email them a shortcut to the XLA with XLA on the shared drive. If possible you don't want an XLA on a local drive.
If the XLA must be on a local drive - not sure if this would work but an XLS on open event could check an fix any paths and install /install a xla - if it knows where its is. But if you were emailing a XLS over the internet, the on open event of the XLS could check if the XLA is available and put up a message box telling the user what to do - install this xla, which would be a separate attachment. The XLA could clean up any paths as part of its on open event - just some ideas.
another possibility is the XLA on open event can modify the XLSs on open event so that if that XLS is distributed the XLS will be able to check if the XLA is available. Tricky.
It's a poor oversight that makes add-ins barely manageable for shared use. Other than this, using .XLAM add-ins is a good way to avoid having to have macro-enabled spreadsheets (the shared spreadsheet can be distributed without macros and the macros can reside in an .XLAM)
Related
A colleague is trying to open an .xlsm book from a network folder but gets this message:
The visual basic for applications (VBA) macros for this workbook are corrupted and have been deleted. The corruption most likely exists in the current file. To recover the macros, open up a backup copy of this file if you have one.
If they download and save the file from an e-mail then open it locally it works fine.
Other people can also open this book from the network and it works fine.
In the failing book, it appears that all objects (worksheets and modules) have been duplicated with a 1 suffix.
Searching this issue online I found several suggestions but none of them seem to fit this scenario.
When working in Excel, sometimes we have external data sources.
In Windows, these files may be stored in a specific location such as C:\Users\Freelensia\Dropbox\data source.xls
When sharing the main file and the data source file with another person through file-sharing services such as Dropbox, the location of the data source will be changed to:
C:\Users\PeterSmith\Dropbox\data source.xls
(from the view of the Peter Smith user)
This will break the data connection in the main file when Peter opens it. He can reset the path to the one as seen from his computer, but that will break the connection for the Freelensia user when he/she opens it from his/her end.
Is there a way to permanently fix these locations for multiple users? Such that Excel will correctly get the path when the right user opens it.
I am looking for an inherent Excel property if such a thing exists. Else VBA macros (A table with the file paths for each user, and MsgBox that ask the user to choose the user profile). Else a Windows .bat file could work as well.
Thank you for your help.
A trick to this is to move your Dropbox to C:\Dropbox for all users.
To do that, click on the Dropbox icon at the bottom-right, click the Gear Icon, Settings, Sync Tab, then you can move the folder to C:\Dropbox.
If you encounter permission errors, follow the instructions here to reset the permissions:
https://www.dropbox.com/help/desktop-web/move-dropbox-folder
If my understanding is right when ever a different user opens/saves a file the path "C:\Users\xxxxxxx\Dropbox\data source.xls" will be same only "xxxxxxx" in the path will be varying with the active user who has logged in.
So use "Application.UserName" function to get the username and use it in the path mentioned above
Excel uses relative links, even though it shows longer paths in the cells when you look at them. This ends up meaning that if you move the file and the file(s) it is connecting to a different location then the links will still work.
If you put your main file in Dropbox\Excel\main.xlsx and then your data sources in Dropbox\Excel\Data\data sources.xlsx then I think you should be good.
I tested this with Google Drive on two different computers, taking turns opening and modifying the data source and also opening and having the main file update without any issues.
I am not positive if this would work for you in Dropbox, but I really think it should... I am using Excel 2010, so if you are using Excel 2003 (or saving files as .xls instead of the newer .xlsx format) there is a possibility that could cause issues.
Recently a large number of security updates were pushed for Microsoft Office at work. We have an Excel tool with a Visual Basic backbone which worked prior to the updates, and now does not work.
I have done some isolated testing and have found that we see the same 'error 75' when using the FileCopy method on .BAT and .EXE files. Other less 'risky' file types seem to be ok. This is also an issue with the 'Open' command.
Does anybody know of a workaround for this issue when copy/pasting .EXE and .BAT files, or maybe this is a known issue with a certain security update? I have searched everywhere, but the Google is failing me. I am hoping either:
Someone knows which security update is the culprit and I can try
uninstalling it to see if that fixes the issue
There is a different way to copy/open/manipulate .BAT and .EXE files that doesn't violate the new security patch.
Some background:
We are using Microsoft Office Professional Plus 2010 and the tool uses Excel as the interface.
Here is the testing code I am using. I have verified that .TXT and .DAT files run just fine while .EXE and .BAT files cause 'error 75' indicating a permissions error. And before you ask, yes, the file path is correct, I have just omitted my employee identification information.
Sub Macro1()
' Declare variables
Dim Filename, SourcePath, DestPath As String
' Pathname variables
Filename = "test.dat"
SourcePath = "C:\Users\<REDACTED>\Desktop\working_copy\" & Filename
DestPath = "C:\Users\<REDACTED>\Desktop\working_copy\test\" & Filename
' Copy file from Source and paste in Destination
FileCopy SourcePath, DestPath
End Sub
Here is an image with the updates that were installed. The tool worked prior to the 6/14/2017 dump, so anything before can be disregarded.
Sorry for the image, too many to enter them manually, no easy way to copy from the update list:
MS Office 2010 Security Updates
Nothing with the tool or file structure changed. The only thing different is the updates. Also, we tested the same tool with Microsoft Office Home 2016 and it worked without a hitch.
Any and all help will be appreciated. Thanks in advance!
While I never found a real fix for this issue, I did come up with a slightly 'hacky' work-around.
The MS security patch prevented me from copy/pasting .BAT and .EXE files, I but could still save .BAT files.
So, I ended up having my script create a text file called "copyExe.txt" which had a single line:
ECHO F|xcopy <source> <destination>
This was then renamed to be "copyExe.bat" and run.
By creating a .txt file, I circumvented the errors when using the VBA Open function on .BAT files (so I could actually create this new batch file). This batch file has the sole purpose of copy/pasting a .EXE file from one folder to another, which circumvented errors when trying to copy/paste .EXE files.
After the copy/paste script is run, it is deleted.
All-in-all it feels like a very silly solution, but it works and is very non-invasive for the user.
We are using TFS as source control system and I would like to implement the following:
We have Excel files on multiple workstations (all connected to TFS) that shall always use the latest version of a macro.
Therefore, I thought about somehow defining the macro in an external file which is under source control and can be centrally maintained and mapped to the local workspace of the workstations where the Excel files are located.
Within the VBA section of the Excel files, there should only be a link to that file so that always the latest version of the macro is used (assuming that the user made a GetLatest operation on the external file containing the macro).
Is a scenario like this technically possible? If yes, how can I define that the Excel file has to import the macro from the external file?
If I understand you correctly referring to the macro containing file as an Addin should do the job.
I've just upgraded to Excel 2010 from 2003. An internal add-in that is heavily used uses the Application.GetSaveAsFilename method to prompt for file names to be used for an export process (exporting information from the current Excel file into an xml configuration file).
In 2003, even if they selected a Read Only file, I didn't get any prompts (which is what I want) leaving it up to me to handle read-only issues (which I do...e.g. I check the file out of source control). However, after upgrading to 2010, I can't select a filename if that file exists and is readonly, forcing me to manually go checkout files first (which is a major downer in terms of proficiency when I'm exporting ~60 files per day).
Does anyone know of any settings/workarounds so that Excel 2010 doesn't prevent (or even prompt hopefully) selecting a filename of a previously existing/readonly file?
Thanks in advance.
Does it help if you use Application.GetOpenFilename instead?
Sub PromptForFilename()
ret = Application.GetOpenFilename
MsgBox ret
End Sub
This doesn't give me any errors for a read-only file.