I recently installed the spreadsheet link ex add-in on my excel 2013, but it doesn't work. When I try to choose the option 'Start MATLAB' from MATLAB field in HOME Ribbon it gives me an error:
'Cannot run the macro 'ribStartMatlab'. The Macro may not be available in this workbook or all macros all disabled.'
The same thing happens with any other MATLAB command chosen from excel.
I chose the option 'Enable all macros' in the Macro Security Settings and also checked the box 'Trust access to the VBA project object model'.
I also checked the SpreadsheetLink2007_2010 reference in the VBA->Tools->References (none other is available).
I found some information that the version of SP for Office might be put to blame but I checked and it seems I have the latest version of SP1 for Office 2013.
The exact name of the add-in is 'Spreadsheet Link EX 3.2 for use with MATLAB and Excel', the Office version is 2013 Proffesional Plus, and the MATLAB version is 2013b. Any help or tips greatly appreciated.
this is more of a guess than anything else. But I'm guessing the ribbon/macros use activeX control. at the end of last year there was an update to excel that disables activeX, which usually results in strange performance or code breaking with very cryptic error messages. It's a bit complicated to get it to work again, but here is a post that might provide some insight http://blogs.technet.com/b/the_microsoft_excel_support_team_blog/archive/2015/03/11/forms-controls-stop-working-after-december-2014-updates-.aspx
again, this is really a guess, I don't know for certain the matlab commands use activeX but it's worth looking into
Related
Since upgrading to Excel 365, my company has been having all sorts of trouble with VBA-supported Excel workbooks crashing or not functioning properly. The issues have popped up in various workbooks and various departments, including seemingly simple VBA workbooks. I've discovered a fix (see below) but it's not sustainable.
The Issues
The various issues we have experienced are listed below. Note, these issues only occur when you open a file in Excel 365 desktop. The same files, when opened in the Excel 365 browser app or in Excel 2016 will work fine. Also, all these issues happen at random. A user may have been working in a file for weeks and then the next time they open the file they get one of these errors.
"Can't find project or library" errors even when we are using the standard set of libraries and basic VBA. Then when you open the VBA Editor window, all the VBA screens are essentially frozen up and the library list is inaccessible.
Excel hard crashes or locks up when opening these files and enabling VBA. Note, the crash only occurs when the VBA is enabled. If you open a file without enabling VBA, it will work fine (though obviously you can't use any of the code).
The file opens seemingly fine, but the VBA doesn't work and once again, everything is locked up when you access the VBA editor window.
"unhandled win32 exception occurred" error
when executing a command, getting an error 32809 which seems to indicate the compiled VBA has been corrupted
The Fix
Opening the VBA Editor window, then selecting Debug -> Compile VBAProject seemingly fixes the issue. I've yet to experience any of the above issues where the file had been manually compiled this way. The problem with this is that every time you add code to a file or any time you add a new tab to a file, you have to go in and perform this manual compile again.
Yes, apparently adding a single tab in a file changes the workbook structure enough that it is necessary to compile again. The Compiled VBAProject selection will be greyed out. But adding a tab (or adding new VBA) will un-grey it and require another manual compile or the problems start occurring again.
This fix also works to repair files where the above issues are occurring. To fix those files, you can:
Make sure "Disable Trusted Documents" and "Disable VBA macros with notification" are toggled on in your security settings so that VBA doesn't automatically run when you open a file.
Open the file with the errors but do not enable the VBA.
Go to the VBA Editor window, select Debug -> Compile VBAProject.
Save the file, close it, reopen it, enable the VBA, and everything works fine again.
But again, this isn't sustainable because all my users will have to remember to go compile VBA any time they add a new tab to a workbook.
Help?
Has anyone found a more sustainable fix to this issue? Is there a bug with the Excel 365 Desktop automatic compiler that Microsoft is working on?
I think I perhaps found an answer in this thread:
https://social.msdn.microsoft.com/Forums/en-US/814ac2ce-ab45-45dc-8c6a-8ef0775d189a/excel-64bit-crashes-when-activating-macros-but-excel-32bit-does-not?forum=exceldev&prof=required
Per that thread – “the cause is that Excel does not correctly save the compile state of the VBA code and 64 bit Excel cannot recover from that issue when opening the afflicted Excel file (32 bit usually can). A fix was released for only Excel 2016 and not for other versions". That would indeed confirm that it is a bug within Excel and explains why we only see the issue with 365 64 bit Excel.
That also explains why my manual compile fix works. Based on the article I found, there is a more sustainable fix. You can change Excel’s registry and force VBA to compile accurately.
To implement the permanent fix:
Open the start menu and type “reg” and select the “Registry Editor”
Navigate to: Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Excel\options
On the Edit menu, point to New, and then click DWORD Value.
Type ForceVBALoadFromSource, and then press Enter.
In the Details pane, right-click ForceVBALoadFromSource, and then click Modify.
In the Value data box, type 1, and then click OK.
I am using MAC OS Mojave 10.14 and Excel version 16.19. I am trying to use the VBA editor to create macros. However, whenever I insert a userform and try to change its properties (such as color, font, etc.) or when I click on an object to complete the word by using list constants, Excel terminates itself and gives this error.
Is there any reason for (or a possible solution to) this problem?
The version you provided means you have Office 2019, not Office 2016.
The ability to insert and edit userforms is not yet supported. Microsoft accidentally turned this capability on for a few users, but the feature isn't even ready for testing, yet. It will come along pretty soon, though, as you can see that quite a bit of the interface is built.
I have an Excel application, with lots of macros in it. The macros in the workbook are signed. Some of the macros call Windows API functions and they have been ported to support 32-bit and 64-bit versions of Excel properly. The application works fine on different configurations (Windows XP, Windows Vista, Windows 7, Windows 8, Excel 2003, Excel 2007, Excel 2010, even some Excel 2013).
The application has been developped on a PC with Windows XP and Excel 2007, using the French Canadian locale.
I have one customer that has the following setup:
Laptop with Mac OS/X
Virtual machine with:
Windows 8 English
Excel 2013 English
When he runs my application, he always gets a Runtime error -2147319784 (0x80028018).
I tried to pin point where the error happens and it seems that as soon as the macros execute something referring to the Excel Object Model (for example: Application.ScreenUpdating = False) I get the error.
I tried to copy the exact line of code that fails in a new Workbook and it works fine without any error.
I have already seen a similar behavior in other versions of Windows and Excel with english versions of the products, and the way to solve the problem was to change de regional settings to US English. I tried it on my customer's machine and it didn't work.
I searched the web and found similar issues with Excel 2002 and I found a post in the Microsoft's Knowledge Base (http://support.microsoft.com/default.aspx?scid=kb;en-us;320369). This post applies to .NET VSTO applications, which is obviously not my case here. I can't change the current thread's locale as suggested in the article since this is not available from my VBA macros. I tried to copy the Excel.exe file to a 1033 folder and rename it to xllex.dll as suggested, but it didn't work either.
I even asked my customer to completely uninstall all Office products from his machine and just reinstall Excel 2013. Still doesn't work.
Honestly, I'm running out of options here... Can anyone help me solve this problem?
Thank you for your help!
Ghis
"Windows API functions" in a Mac. Can't imagine that'll work. Is your error this? "Old Format or Invalid Type Library" I'd say your code is not compatible with Mac somehow.
I don't know why the code would fail on a minor issue like Application.ScreenUpdating = False; but you already concluded that line by itself wasn't the problem anyway.
Sounds like you'll need to rewrite your code for the Mac.
I have a very simple Excel Addin build it in Visual Studio 2008 for Excel 2003, which creates a toolbar with some buttons.
When I debug it, with System Format set to "English (United States)" it works great, without problems.
However, this addin is going to be used with System Format set to "French (France)" too, and when I try to debug my addin under this configuration, the toolbar (which is created by the addin) is not being shown.
While I'm debugging I can see that the methods that create the toolbar are executed and the code returns fine, yet I can't see anything in Excel, and if I switch back the format to English it works again.
Does anyone know which could be the reason?
I had a similar problem with an add-in that I built for Excel 2000. Although the tool bar would show, nothing was on the toolbar. I was able to correct the issue by downloading the
office multilanguage pack 2003.
Here is a link to it, assuming you do not already have this installed it may be worth a shot.
http://office.microsoft.com/en-us/ork2003/HA011402201033.aspx
In the end, there was a problem related with the decimal separator, which changes for French language, and a validation that I was doing in my code, I missed that part when debugging, thanks for the answers anyway.
So I'm having to run someone else's excel app on my PC, and I'm getting "Can't find Project or Library" on standard functions such as date, format, hex, mid, etc.
Some research indicates that if I prefix these functions with "VBA." as in "VBA.Date" then it'll work fine.
Webpages suggest it has to do with my project references on my system, whereas they must be ok on the developer's system. I'm going to be dealing with this for some time from others, and will be distributing these applications to many others, so I need to understand what's wrong with my excel setup that I need to fix, or what needs to be changed in the xls file so that it'll run on a variety of systems. I'd like to avoid making everyone use "VBA." as an explicit reference, but if there's no ideal solution I suppose that's what we'll have to do.
How do I make "VBA." implicit in my project properties/references/etc?
-Adam
I have seen errors on standard functions if there was a reference to a totally different library missing.
In the VBA editor launch the Compile command from the menu and then check the References dialog to see if there is anything missing and if so try to add these libraries.
In general it seems to be good practice to compile the complete VBA code and then saving the document before distribution.
I had the same problem. This worked for me:
In VB go to Tools » References
Uncheck the library "Crystal Analysis Common Controls 1.0". Or any library.
Just leave these 5 references:
Visual Basic For Applications (This is the library that defines the VBA language.)
Microsoft Excel Object Library (This defines all of the elements of Excel.)
OLE Automation (This specifies the types for linking and embedding documents and for automation of other applications and the "plumbing" of the COM system that Excel uses to communicate with the outside world.)
Microsoft Office (This defines things that are common to all Office programs such as Command Bars and Command Bar controls.)
Microsoft Forms 2.0 This is required if you are using a User Form. This library defines things like the user form and the controls that you can place on a form.
Then Save.
I have experienced this exact problem and found, on the users machine, one of the libraries I depended on was marked as "MISSING" in the references dialog. In that case it was some office font library that was available in my version of Office 2007, but not on the client desktop.
The error you get is a complete red herring (as pointed out by divo).
Fortunately I wasn't using anything from the library, so I was able to remove it from the XLA references entirely. I guess, an extension of divo' suggested best practice would be for testing to check the XLA on all the target Office versions (not a bad idea in any case).
In my case, it was that the function was AMBIGUOUS as it was defined in the VBA library (present in my references), and also in the Microsoft Office Object Library (also present). I removed the Microsoft Office Object Library, and voila! No need to use the VBA. prefix.
In my case, I could not even open "References" in the Visual Basic window. I even tried reinstalling Office 365 and that didn't work. Finally, I tried disabling macros in the "Trust Center" settings. When I restarted Excel, I got the warning message that macros were disabled, and when I clicked on "enable" I no longer got the error message.
Later I re-enabled all macros in the "Trust Center" settings, and the error message didn't show up!
Hey, if nothing else works for you, try the above; it worked for me! :)
Update:
The issue returned, and this is how I "fixed" it the second time:
I opened my workbook in Excel online (Office 365, in the browser, which doesn't support macros anyway), saved it with a new file name (still using .xlsm file extension), and reopened in the desktop software. It worked.
Even when all references are fine the prefix problem causes compile errors.
What about creating a find and replace sub for all 'built-in VBA functions' in all modules,
like this:
replace text in code module
e.g. "= Date" will be replaced with "= VBA.Date".
e.g. " Date(" will be replaced with " VBA.Date(" .
(excluding "dim t As Date" or "mydate")
All vba functions for find and replace are written here :
vba functions list
For those of you who haven't found any of the other answers work for you.
Try this:
Close out of the file, email it to yourself or if you're at work, paste it from the network drive to your desktop, anything to get it to open in "protected mode".
Now open the file
DON'T CLICK ANY ENABLE EDITING OR THE YELLOW RIBBON
Go to the VBA Editor
Go to Debug - - Compile VBA Project, if "Compile VBA Project" is greyed out, then you may need to click the yellow ribbon one time to enable the content, but DO NOT enable macros.
After you click Compile, save, close out of the file. Reopen it, enable everything and it should be OK. This has worked for me 100% of the time.
In my case I was checking work done on my office computer (with Visio installed) at home (no Visio). Even though VBA appeared to be getting hung up on simple default functions, the problem was that I had references to the Visio libraries still active.
I found references to an AVAYA/CMS programme file? Totally random, this was in MS Access, nothing to do with AVAYA. I do have AVAYA on my PC, and others don't, so this explains why it worked on my machine and not others - but not how Access got linked to AVAYA. Anyway - I just unchecked the reference and that seems to have fixed the problem
I've had this error on and off for around two years in a several XLSM files (which is most annoying as when it occurs there is nothing wrong with the file! - I suspect orphaned Excel processes are part of the problem)
The most efficient solution I had found has been to use Python with oletools
https://github.com/decalage2/oletools/wiki/Install and extract the VBA code all the modules and save in a text file.
Then I simply rename the file to zip file (backup just in case!), open up this zip file and delete the xl/vbaProject.bin file. Rename back to XLSX and should be good to go.
Copy in the saved VBA code (which will need cleaning of line breaks, comments and other stuff. Will also need to add in missing libraries.
This has saved me when other methods haven't.
YMMV.