I have a simple excel VBA that is referring multiple files and copying information across to a master before processing. While building this on my own system a workbook reference (working perfectly fine) was written as:
Workbooks("key").Sheets("Sheet1").Range("A1:X57").Copy
Here key is a .xlsx file
While using this in another system this does not work and it explicitly requires the file extension in every call.
Workbooks("key.xlsx").Sheets("Sheet1").Range("A1:X57").Copy
It would not be extremely difficult for me to make this change although I wanted to understand why this is happening and can I define an Option (guessing!) that would not require me to do so?
Why is there difference in behaviour across systems while running the same script?
Any help would be much appreciated. For me this seems like VBA having a mind of its own.
If the key.xlsx file is saved on both systems, including the file extension when referring to the Workbook objects is the safer option because of Windows hide extensions setting:
The Workbooks Collection Object
If the hide extensions setting is not in effect (meaning that
extensions are indeed displayed in Windows), you must include the xls
extension when you reference a workbook in the Workbooks collection.
For example, if you have open a workbook named Book1.xls, you must use
Workbooks("Book1.xls").Activate
rather than
Workbooks("Book1").Activate
to refer to the Book1 workbook. The second line of code above, without
the xls extension, will fail with an error 9, Subscript Out Of Range,
because there is no workbook with the name Book1. If the hide
extensions setting is effect, you can omit the xls extension and use
either of the following lines of code.
Workbooks("Book1").Activate
Workbooks("Book1.xls").Activate
These lines of code assume that you do not have open both an unsaved
workbook with the name Book1 and a saved workbook with the name
Book1.xls. With the hide extensions setting enabled (so that
extensions are hidden in Windows), the two lines of code above are
functionally equivalent. As a matter of good programming practice, you
should always include the xls extension in a workbook name. This
ensures that you reference the correct workbook regardless of the
value of the hide extensions property.
More details from cpearson.com for File Extensions And Their Implications In VBA Coding
Related
I wanted to save all my VBA Project in a Excel workbook (or other type of file if possible) and then embbed it to run in another workbook. I've seen topics about it but only found ways to run the macros opening the first sheet.
I want to run a macro from a first workbook in a second one without opening the first workbook to do it. How can I do that?
Save the file with the macros as a xlam file and Excel can load them each time Excel opens.
You need to open File -> options -> add-ins.
At the bottom there is a button Go to (or something, I don't have English Excel on the current computer.)
Then add the file to the list by clicking Browse and finding the file you just saved as xlam file.
Two scenarios comes to mind:
1) You have a second macro for personal use and can save it locally (save in: %USERPROFILE%\AppData\Roaming\Microsoft\Excel\XLSTART). This will allow you to create quick-buttons for your macros, etc. These types of macros open with Excel and will be separate VBA Projects inside of the default VBA editor.
2) You have a network or drive that multiple users need to access, so each user has a macro in their file (.xlsm or .xlsb), where that internal macro reads Application.Run "filepath\workbookname.xlsb!macro", which also allows you to call a private subroutine (note that you could use Call, but Application.Run will ensure that even Private macros are able to be accessed). This shouldn't require the other workbook be open, though I have personally had one user whose computer always opens the other file, regardless.
Edit:
Third scenario (really 2b):
3) You have files where you want to regularly access another file... you will follow a similar approach to point 2 where you make a macro to Application.Run, though you can save that macro in your XLSTART folder... this will allow you to have a source macro location where others may also want to access and utilize. The source document would allow you to maintain 1 file for many users.
Your answers were great! Great to know about XLSTART folder from #Cyril, but based on #Andreas answer I found my path.
The "problems" with adding an Add-In as #Andreas said, are cause my VBA Project would be avaliable on the VB Editor to every workbook on that computer, and to run my macros I'd have to use Application.Run("workbook.xlam!Macro").
Then I found References, which I have the same features, including I can delete my .xlam file to remove my code, and don't have the problems I mentioned above.
Adding my VBA .xlam file as an reference, it'll be avaliable only to that specific workbook and I can run my macro just like it was on the same workbook.
For general knowledge:
ADDING A REFERENCE:
1- Save your project as an Excel Add-In (.xlam file)
2- Open your target workbook, go to the Visual Basic Editor
3- Go to Tools > References > Browse... find your .xlam file and make sure it's checked.
4- Done! Now you'll see the project on the editor and can run your macros just like it was on the same workbook.
In a perl script I am writing, I am trying to find a way to open an existing excel spreadsheet, change the name of the first worksheet, and save it. It would seem like a simple task but I haven't found a simple way to do it.
Spreadsheet::WriteExcel can easily change worksheet name, but it seems like it can't read in an existing excel file.
Another constraint is that the perl module I use shouldn't need installation. I can work around this if there's no good option, but it would make things more complicated.
Edit: I am using ActivePerl 5.18, so modules included in this are ideal.
The only way of doing this while preserving everything else in the Excel file is to use Win32::OLE.
That requires having Excel installed on the computer on which the program will be run, and, of course, only works on Windows.
If you can't do that, you will have to read the Excel file, and write out the contents to another file, changing the name of the worksheet in the process. Depending on exactly what you have in the source Excel file, this can get rather involved rather fast.
See also "How can I merge two Excel (xls) files in Perl or batch?" and "In Perl, how can I copy a subset of columns from an XLSX work sheet to another?"
I wrote an Excel add-in that provides UDFs (user-defined worksheet functions).
All is well until one user sends his workbook using those functions to another user, or just tries to use the workbook on more than one computer, where the add-in has been installed to different paths.
Even if the only difference in the paths is the drive letter, when the workbook is opened on the other computer, the old full path appears on the formulas in front of all the UDFs, and the formulas return an error.
One way of dealing with that is doing a search & replace of all formulas in the workbook, replacing the path with an empty string. Then the formulas reset themselves for the add-in's path on the current computer. Sometimes I then have to go into the VBE and run a CalculateFullRebuild to get the formulas to work. Though it works, it's a lot to ask of the less technical users, and it's annoying to have to do it frequently for those users who move their workbooks around a lot.
Also -- do COM add-ins have this problem? My add-in is an xla. Though I'm curious about that, it's a moot point in this case since COM add-ins don't work on Macintosh Excel and I need this add-in to work cross-platform.
UPDATE:
As requested, here's a screenshot:
This screenshot shows what happens if Fred, who put the add-in in C:\Fred's Stuff\Fred's Excel Stuff\MyAddin.xla, sends his workbook to Martha, who put the same add-in in another path, such as C:\Martha's Files\Martha's Excel Files\MyAddin.xla, and Martha opens the file Fred sent.
If Martha deletes the path, leaving only "=MyUDF()" in the formula, Excel will find MyAddin.xla on Martha's computer in the path where Martha put it (assuming she had previously installed MyAddin.xla as an add-in in Excel), and resolve the formula correctly.
This is one of the many bugbears Excel developers need to face at one time or another, and there are a few work-arounds for it, but which one you choose will depend on your own circumstances:
http://www.jkp-ads.com/articles/FixLinks2UDF00.asp
In case the link dies, here is a summary of the three suggested methods:
Use fixed locations.
Instead of keeping your UDF code inside the addin, you create a facility that copies the UDF routine into each workbook that uses it.
Redirect the UDFs to the new location.
I'm using Excel 2010 and adding a small VBA macro to a spreadsheet. (The purpose of the macro is to take the data on the active sheet and export it to a CSV file, but that's tangential to the question.) The macro determines the output path for the file using ThisWorkbook.Path. I also added a custom button to the Quick Access Toolbar to activate the macro.
After getting a working algorithm in place in my experimental spreadsheet (Test.xlsm, stored in one path), I made a copy of the spreadsheet in another path and renamed it to _Database.xlsm. Then I opened _Database.xlsm and ran the macro. To my surprise, the file was written to the original path, not the new one. And looking down at the Windows toolbar, I saw that Excel had opened the original file over in its original path as well.
After a lot of jiggering around with code tweaks, checking properties and such I finally found that I could prevent this by opening the copied spreadsheet, removing the Quick Access Toolbar button, re-adding it, and then saving the file. My questions are:
Why isn't the macro "independently portable" along with the spreadsheet? I.e. why does the copy maintain this kind of tie to the original sheet?
Is there a way I can create or modify the macro to make it portable in that sense?
If you want a toolbar/button to travel with a file (ie. not always link back to the original version) then you need to add it to the file itself, not to the QAT. The QAT only "knows" about the actual file you linked the button to.
It might be better to add the macro to your Personal Macro Workbook and then just have it operate on the ActiveWorkbook.
However, if you want to distribute it to other users, you can keep the macro in the "database" workbook and add a custom ribbon part. See: http://www.rondebruin.nl/win/s2/win001.htm
I'm trying to get a simple VBA function to run in an excel (.xlsm) worksheet.
I created this function:
Function abc()
abc = 2
End Function
in Module2, and it worked.
But after I copied the spreadsheet to another system, it now just shows "#name" as if it can't find it. The function shows up on the available list of functions however.
This makes me think there is some kind of setting I need to enable, but I've enabled whatever I was prompted for. Any ideas?
I should've known it was in the trust center:
http://office.microsoft.com/en-us/excel-help/change-macro-security-settings-in-excel-HP010096919.aspx
Basically, hit the ball and poke around until you find "trust" and "enable macros" and select the least secure options.
And then close and re-open the spreadsheet.
I think we may need more information. What version of Excel are you using? Is it different from the destination system version?
You'll want to make sure that Module2 was in the Workbook you copied into the other system. Excel 2007 stores macros on a personal workbook by default sometimes so you'll need to check the the code is actually inside of the .xlsm file.
If you're still stuck and need a quick fix just copy the code text into the new system's Excel workbook directly without making a .xlsm file (create new module in the other system then paste).
If you would like to learn how to put together add-ins you can get started here or here.