I ran into a strange Excel 2013 VBA behavior today and felt posting the solution to the problem may help someone else in the future.
The following command worked fine on my computer and most others but one user would get an error message. I'm using Windows 7.
Workbooks("Book1").Activate
What I found out was that the other user has 'extensions for known file types' shown. By default Windows wants to hide those. In order to get the code to work properly on all machines, I had to include the file extension in the code as shown below. When a new workbook is created and has not yet been saved, it does not need a file extension included in this command as it is not yet determined.
Workbooks("Book1.xlsm").Activate
Just guessing, but this may be related to a setting in "Folder options" of Windows Explorer.
On the View tab there is an option "Hide extensions for known file types" - this will affect how you can refer to workbooks by name in VBA.
EDIT: seems you got there already!
I've already had the file extensions enabled but it didn't work. I fixed by forcing the file and sheet to activate.
Example (while the files are still open):
Windows("file2.xlsm").Activate
ThisWorkbook.Worksheets("sheet2").Activate
I know that Activate and Select are inneficient, but if it works..
Hi in your code use two dim for workbooks like
dim currentwb,newwb as workbook
set currentwb = ActiveWorkbook
and once you create your new workbook set
set newwb = ActiveWorkbook
Related
Hi have a macro that open some excel files, take some rows and close the file.
Everything works like a charm but I need to add a small feature.
On some of the files, once open, I see the message about some reference to external files missing and the option to update or not the sources.
The following is a picture of the message.
I need to click each time on "don't update" and I'd like to authomatize this action while the macro runs.
How to do it? From my research I have found how to dismiss completely messages from excel while the macro runs but I'm not sure this will solve my issue
Since you are only reading data so open them read only and tell VBA not to update the links so it will not ask you that at all:
Dim WB As Workbook
Set WB = Application.Workbooks.Open(Filename:=MyWorkBook, UpdateLinks:=False, ReadOnly:=True)
Where WB is the workbook that gets opened and MyWorkBook is the full name (path of the workbook) e.g. C:\MyDrive\MyWorkbook.xlsx
I have an issue with my Excel workbook. I have code both in modules and embedded in the sheet.
Until recently, everything was working fine but suddenly the code embedded in the sheet does not work.
I have a sub routine for right clicked cells. This used to create a drop-down menu of its own rather than the standard right click menu but recently it stopped working. I have tried deleting the entire code and simply putting msgbox("Test"), but it still doesn't work.
Macros are enabled as this is the interesting thing ... if I right click the sheet tab and copy it ... the new version works absolutely fine. It is as if the original sheet has become corrupt.
This is further evidenced by when I try to delete the original sheet manually (right click tab and delete).
This causes Excel to crash.
I can delete any other sheet no problems.
However, a colleague of mine opened the workbook and it works fine for him without having to duplicate the sheet.
When it first happened I did the duplicate fix then renamed the original to "OBSOLETE". Not a pretty workaround, but worked nevertheless.
It has now happened again, however, and I am reluctant to keep patching it in this way.
If I try to address the sheet using VBA from another sheet:
Code in sheet 2 ("Slave"): msgbox(sheets("Master").cells(1,1).value)
it gives the following error:
Run-time error 32809: Application-defined or object-defined error
I have tried addressing it as sheet1.cells instead of sheets("Master").cells as well and this gives the same error.
Changing the code to point to Sheet3 works fine. It is literally just this sheet causing problems.
I tried 'open and repair' on the document too.
I have read around extensively and tried the deletion of .exd files etc. No luck.
Any thoughts? It seems independent of code - more a specific issue with this workbook and its sheet which over time becomes 'corrupt' but only for some machines/users.
There is also a command button in the sheet. This also does not work (clicking it just does nothing). If I go into the VBA editor and manually activate the sub-routine, I get the following error:
Compile error:
Object library invalid or contains references to object definitions that could not be found.
Again, this still happens even if I strip the code right down to a simple msgbox operation.
Any thoughts would be appreciated. Thanks
Hi i am having the same issue running code that populates combo boxes on my sheet. It seems that the sheet index is being deleted so the workbook o longer 'sees' the sheet you are trying to reference.
A simple workaround i found is to resave the workbook with a different name and it should work fine but this is not ideal when it is running on a regular basis. It does however allow you to recover the original workbook after it has been corrupted on the other machine.
It seems that some security updates made by microsoft in December 2014 have resulted in issues running sheets across the old and new machines. They are aware of the issue and are working to resolve it. This blog explains the issues and work arounds:
http://blogs.technet.com/b/the_microsoft_excel_support_team_blog/archive/2014/12/11/forms-controls-stop-working-after-december-2014-updates-.aspx
Their solution provided on the above blog requires all users to have this update and then to delete all .exd files from the temp folder that are related to the issue and then recompile the code (this still requires all machines to have the new update).
Another option (the one I will be taking until they resolve the issue) is to roll back the problem machines to a pre Dec version prior to making the update.
Hope that helps!
i have an issues with an macro that i'm writing. I have my xlsm file that i'm writing my macro in, it's creating a template that gets data from multiple spreadsheets that other people send me. However one file that i use for information is an xlsm file and is giving me problems. I believe i have isolated the problem but am unsure as to how to fix it.
the first sheet is named "Piranha" (no idea why), and the second sheet is named "Piranha - Dist & Growth split"
however when i write stardard code like
Sheets("Piranha").select
it has a runtime error 40036 (Application- defined or object defined error)
it also doesn't like
ActiveSheet.select / .name
but only for those two sheets, there is another sheet named "Exceptions" and i can use that object no problem. Has anyone ever heard of this problem or better have any ideas on how to solve it? Also because it's not my file if there is a way to do it without actually altering the file would be amazing. Thank you!
I had similar problem error 40036 and debugging pointed to a file path variable. When deleting or adding line of code the error moved...
I tried solution from Expert Exchange:
from VBA window do Debug>Compile VBAProject
fix any error raised
I fixed the error and it all works fine now :)
Thanks guys for your help, however i fiiiinally figured out that when trying to manipulate the file to get the data the macro of the file would interfere with my process, so i just make a copy of the file and delete all vb components and my code works fine
In the file which is a problem, try compiling the VBA project (via Debug > Compile VBA Project in the VBA editor) and see if there is an error in any code in the relevant sheet modules
Sub test()
Sheets("Sheet1 & 2").Select
ActiveSheet.Select
End Sub
Sub test2()
Sheets("Sheet1").Select
ActiveSheet.Select
End Sub
Tested your issue with the above code and I was unable to replicate your fault. Perhaps there is a space at the beginning or end of one of the sheets? As for ActiveSheet not working, it works OK in my test. I think you need to check your code, or at least update your Question with your code so we can check it
All these answers talk about compiling and clearing errors. If you're like me, you do that all the time. The answer didn't seem clear to me so here it goes:
Not only does your macro workbook need to be free of errors, so do ALL other workbooks you open. So if you're digging through a ton of data and you hit these bizarre object errors then it's possible there is a workbook with compile errors in your dataset. No amount of debugging your main workbook will fix the problem.
You have to be able to successfully compile every workbook you open programmatically. The OP said something about stripping "the vb components" out of his data. Any method like this you can do that avoids macros in your target data workbooks will work-around this issue. You can save each file as macro-free XLSX and then pull data from that. Or you could use ADO to access the data in a query.
I have the same problem and solved it by first finding which sheet was being accessed at the time of the error.
I copied all the data from that sheet (including formulas, formatting) and pasted into a new sheet along wit the sheet's VBA code. I deleted the old sheet and renamed the new set back to the old sheet.
On other words, I recreated everything back to what it was.
The error disappeared.
I need to link up an .xls (must not have macros) to a macro on our network. I thought I had found a good solution, which uses a shape to link up to a macro that is set an add-in in Excel. This method worked well for over a year, but now things are starting to act REALLY ODD. Excel keeps changing my links from the network to the local drive!
Basically, at my computer I run code that creates a button and sets the .OnAction value to 'SPC_BUTTONS.xlam!EXPORTSPC' which excel sometimes updates to 'G:\NetworkLocation\SPC_BUTTONS.xlam!EXPORTSPC' (sometimes it leaves it alone). I linked up the add-in to run from the network (and don't copy it locally) so this is a correct address for it. However when I move the file from my computer, to the network and on to the final computer, the link will change to 'C:\NetworkLocation\SPC_BUTTONS.xlam!EXPORTSPC'. The file's links work until the point it lands on the local computer.
'Check if SPC Button already exists
Dim exportButton As Shape
On Error Resume Next
Set exportButton = InspectionWS.Shapes("SPC Button")
On Error GoTo 0
If Not exportButton Is Nothing Then
'Delete the old button
InspectionWS.Shapes("SPC Button").Delete
End If
'Create "SPC Button"
InspectionWS.Shapes.AddShape(msoShapeRectangle, 770, 600, 160, 36).Name = "SPC Button"
Set exportButton = InspectionWS.Shapes("SPC Button")
With exportButton
.ShapeStyle = msoShapeStylePreset34
.TextFrame2.TextRange.Characters.Text = "Export SPC Data"
.TextFrame2.TextRange.Font.Size = 20
.TextFrame2.WordArtformat = msoTextEffect8
.OnAction = "EXPORTSPC"
End With
The first time I saw this problem was when I had changed the add-in. I had made another macro in that file called EXPORTSPC2, and had swapped names with original when it was time to go live. That's when all of the links became broken. I swapped back the names and decided to just swap the code, in case position mattered. Still didn't help with the linking.
I looped the original macro that set up the buttons on every file again, but that failed to rectify the problem. Several hours later, after trying a lot of options I found setting .OnAction to just 'EXPORTSPC' did again get some files to link up again, but ONLY if I did it on the local computer. I had tried the full address, a local address (and moving the add-in location), and SPC_BUTTONS.xlam!EXPORTSPC and of those still ended up with 'C:/Networklocation.xlam!EXPORTSPC'... even when set on the local computer.
The problem is, yesterday, it happened again when someone had replaced the updated files with another set of files he had been modifying on the network. This time around I wasn't surprised to see that they didn't link up (although disappointed), but was surprised that the my code looping the update to EXPORTSPC failed to 'take' for all of the files on the second computer. Only a handful of them would actually change to EXPORTSPC, and I ended up having to assign the link locally on the final computer(s), by hand, for each of the 45 .xls files.
Really, I can't keep doing any of this local repairing, as it creates machine downtime.
So my questions! Is there a better way to do what I'm trying to accomplish (.xls to add-in)? Any idea as to why is moving these files causing excel to change the link, forcing me to set them up locally? Why does it suddenly not accept anything but EXPORTSPC as the link name? Does excel save some sort of ID for macros/add-in/buttons I'm unaware of I'm accidently breaking?
Really, Any sort of insight will help. Thanks!
EDIT:
I did find an error in my looping code, which effected the issue I had on the second computer. It was looping through each workbook fine and saving... but I didn't activate the workbook before running the code, which was pretty important (DOH!). This only resolves the problem I ran into yesterday where I had to edit by hand.
However, digging a little deeper, I do feel like I have a better understanding. I used the code below to determine if what I see in 'Assign Macro' matches the stored .OnAction value, which it does not. Testing on my computer this code:
exportButton.OnAction = "'G:\NetworkLocation\SPC_BUTTONS.xlam!'EXPORTSPC"
would cause the 'Assign Macro' to change to 'EXPORTSPC', even though debugging
debug.print exportButton.OnAction
still displayed the original OnAction value. When I moved the file to the shop floor computer, 'assign macro' would display 'G:\NetworkLocation\SPC_BUTTONS.xlam!'EXPORTSPC until I clicked it, and then it would switch to EXPORTSPC.
So it seems Excel does keep track of where the macro is located once it detects the correct location. I swapped the macros around and it seemed to have broke the connection. My guess is excel then modifies the location to the C:\ once it's internal link is broken. If anyone has any elaboration/verification of this, I'd love to hear it.
I do recall having the add-in button becoming unchecked randomly, which may have been playing into why links kept breaking and reverting to the c:\ while I was debugging what would work. I'm not sure what was causing that either. But using the all forms of exporting seemed to work today. I'm still not convinced that I won't see it again though, since I don't fully understand what was the catalyst of unchecked boxes and swapped links.
If Not exportButton Is Nothing Then
With exportButton
.OnAction = "'SPC_BUTTONS.xlam'!EXPORTSPC"
'.OnAction = "EXPORTSPC"
'.OnAction = "'G:\NetworkLocation\SPC_BUTTONS.xlam'!EXPORTSPC"
End With
Debug.Print exportButton.OnAction
End If
So parts of the process still seem fuzzy, but at least now I know how to better track what I'm seeing.
Try this -- qualify the Add-In filename:
.OnAction = "SPC_BUTTONS.xlam!EXPORTSPC"
I have tested this with an XLAM on a network drive, and an XLS file on my desktop. I have copied the XLS file to a network location, and it still works. I have also done a SaveAs to put the XLS file on yet another network drive, and the action continues to work.
This of course requires that the user's instance of Excel has the Add-In enabled.
Alternatively, try enclosing the path & filename in single-quotes:
.OnAction = "'G:\NetworkLocation\SPC_BUTTONS.xlam'!EXPORTSPC"
This method seems to be preserving the OnAction absolute path.
This post is about installing XLAM's without creating links. (Everyone hates links). Consider the trivial addin:
Public Function UDF_HELLO(x)
UDF_HELLO = "Hello " & x
End Function
Put this code and nothing else into a Module and save as "Hello.xlam" on the Desktop (and NOT in the default excel addins folder). Next, while HELLO.XLAM is still open, create a new XLSX workbook with the formula
=UDF_Hello("world")
in cell A1, which simply displays "Hello world" in that cell. Save the workbook and exit Excel. Now, if you reopen the workbook without the XLAM, Excel will complain about "links to other sources ...". Whether you click "Update" or "Don't Update", Excel will mangle the formula in cell A1 like this:
='C:\Documents and Settings\tpascale\Desktop\Hello.xlam'!UDF_Hello("world")
Very often this "forced-linkage" is NOT desirable. In my computing environment there is a lot of ad-hoc analysis and it makes no sense to impose an install regimen on every XLAM we throw together to solve the problem of the day. I just want to hand out XLAM files to users and let those users open them when they need them, WITHOUT having to worry about the slightest mis-step causing their formulas to get mangled.
QUESTION:
Is there a way to instruct Excel to NEVER construct external links for UDFs, and simply to use UDFs if they're loaded and return #VALUEs otherwise ?
I don't know of a way around this with .xla/.xlam add-ins.
But this issue does not occur with .xll add-ins.
These can be created in C using the Excel 2010 SDK, or in managed languages like VB.NET or C# using the free Excel-DNA library.
(Disclaimer: I'm the developer of Excel-DNA. This issue is one of the reasons I went with the .xll interface for making managed UDF add-ins.)
You can have them open the .xla file and have an Auto_Open procedure install the add-in.
http://www.vbaexpress.com/kb/getarticle.php?kb_id=693
After excel closes you can have the add-in uninstall itself.
oAddIn.Installed = False
You can give your add-in a setting for the user to not uninstall after every use by using a worksheet named something then have cell A1 equal to true or false.
I haven't tested this but hopefully it works for you.
This should work to resolve your issue though it does not instruct Excel regarding external links. I have tested it myself by creating the XLAM, saving it to my desktop, installing it in the Excel add-ins and then using it on a new workbook.
Steps:
Once you have saved the add-in, close it.
Go to Excel Options-->Add-Ins
In the Manage drop-down select Excel Add-ins and press 'Go'
In the 'Add-Ins'dialogue that appears click 'Browse' and navigate to
the add-in you just created. Select it and hit 'Ok'
If prompted to save the add-in in the add-ins folder, select 'No'.
Selecting 'Yes' may cause an error if the add-in file suffix does
not match the version of Excel being used.
Your add-in should appear in the 'Add-Ins available' scrollbox,
check its box and hit 'Ok'
Your add-in should now be active whenever you open Excel.
Test this by opening a new workbook and try using your UDF.
Best,
I usually solve this problem by:
Saving an XLA/XLAM file (outside Personal folder, of course)
Connect to it in Tools - Addins
Write pseudo macros in your current Excel file that links to those macros / functions in the XLA/XLAM file.
See the detailed instructions in my reply here.