Macros refuse to run for me in Excel 2007 on Windows Server 2003.
The macro and visual basic icons on the ribbon are grayed out.
If I open a workbook with a macro, I get the warning: " This workbook has lost its VBA project, ActiveX controls and any other programmability-related features."
If I try to make a new excel template in VSTO (Excel is closed at the time), I get the error: "Programmatic access to the Microsoft Office Visual Basic for Applications project system could not be enabled. . ."
I checked that VBA was installed (originally it wasn't, I added it via office setup). I also tried uninstalling and reinstalling office and VBA, no dice.
I made a macro-enabled workbook.
I set the workbook's location to trusted.
I configured all of the security settings available under Excel Options/Trust Center to allow-everything-no-prompts.
I set "Enable all macros" and "Trust access to the VBA object model".
I downloaded the group policy admin templates and verified none of this is being set via group policy.
That's everything I can find in Google to try, but clearly there is another place that VBA can be turned off. Where else can I look?
Are you sure there isn't a system policy in place that inhibits VBA?
Edit: Some reading, if you've not already seen these:
http://support.microsoft.com/kb/282847/en-us
http://support.microsoft.com/kb/287567
http://support.microsoft.com/kb/281954/en-us - Applies to earlier versions, but some/all may still be relevant to 2k7
Alt+F11 in excel and see if there is an option in there that you can change....
Related
There are instructions online for sideloading an addin into Excel for Windows.
However, I get stuck on step 4. Namely, there is no Manage My Add-in's button anywhere within the MY ADD-INS page that I can find.
Does this button still exist somewhere, or are the instructions out of date? If the button is gone, is there any other easy way of side-loading an add-in into Excel?
There are other instructions online for sideloading an add-in, but they are much more complicated and hard to follow.
Thanks for any information!
The page that you linked to is for sideloading in Excel on the web, not Windows. For Excel on Windows, see Sideload Office Add-ins for testing. BTW, its best to work with the help on the learn.microsoft.com domain. The GitHub repo that you linked to is the source files and its harder to find your way around there.
I've seen posts from several years ago stating that automation wasn't supported in older click to run installations of Office, eg 2010. Can anyone tell me if this is still the case with Office 365?
For background, the reason I'm asking is I support some .NET desktop applications which use late-binding to automate Excel and Word. They've worked fine for all users until a recent client who has Office 365 Business click to run. On this PC (and this one only, so far) the app fails ("Cannot create ActiveX component") at the line:
Dim oExcel as Object = CreateObject("Excel.Application")
User claims Excel is definitely installed and working (and Registry key at /HKEY_CLASSES_ROOT/Excel.Application/Curver confirms 2016 is present.) Also CreateObject("Scripting.FileSystemObject") executes correctly, so it doesn't seem to be a scripting problem.
Thanks for any assistance!
Excel addin which uses Excel API 1.2. Add-in loads fine in Excel 2016 for Windows and Excel online. Save the file from Excel online and open in Excel 2013, addin fails to load in Excel 2013 with following errors:
When loading the Addin published in Store:
APP ERROR We can't load this app because we could not connect to catalog
When sideloading the addin from trusted catalog:
This app could not be started. Close this dialog to ignore the problem or click restart to try again
I know that Excel 2013 does not support Excel API 1.2. Could you please confirm the recommended way to make sure the add-in loads in Excel 2013?
• Should we use runtime checks using isSetSupported method?
• In such cases, how to debug which line of code is failing in Excel 2013 client?
• Is there any logging that can be enabled to troubleshoot such issues in Excel client?
I tried debugging a default add-in created by VS 2015 which uses Excel 1.2 API in Excel 2013. I added the following requirements set to the Manifest:
<Requirements>
<Sets DefaultMinVersion="1.2">
<Set Name="ExcelApi" />
</Sets>
</Requirements>
The addin also fails to load in Excel (15.0.4849.1003) when debugging using VS 2015. It works fine in Excel 2016 client.
I think there are two separate issues here (though there's a good chance that they're related, and the platform is simply giving the wrong error string. If so, let's confirm, and then I can file a bug to have us fix this).
Excel 2013 does not support the "ExcelApi" requirement set, which is a 2016 addition of the host-specific APIs (same goes for "WordApi"). If you specify ExcelApi in the requirements section of the manifest, as you have above, this will always fail to load in Excel 2013 -- by design. Essentially, you're requesting an API set and marking it as "required" for something that Excel 2013 does not support -- so it has no choice but to refuse to run it.
This is where the runtime check (isSetSupported) comes in. Please see my answer at Neat ways to get environment (i.e. Office version) for more details.
I am not sure what you mean by "how to debug which line of code is failing" or troubleshooting techinques. Essentially, any call to an Office 2016 API (anything in the ExcelApi set) from 2013 will result in a runtime failure...
Hope this helps!
I am supporting a legacy application that was written in Access 2003 using VBA. We are updating our systems to Office 2010, with the exception of Access, which will remain the 2003 version. (This is due to several factors pertaining to other groups in my organization.)
We use Access as a front end for running reports out of MS SQL and Sybase databases. Some of these reports open in Excel. During testing, running reports that write to an Excel workbook causes the Access application to crash and exit without a warning message - the application simply disappears from the screen.
I'm not sure what the cause of this is or where I should start looking for answers. Has anybody dealt with a similar situation?
I saved and recompiled the application on the development machine that had Office 2010 installed, and thereafter the application worked correctly with Office 2010 (of course, it no longer works on machines only having Office 2003.) This was, of course, after checking the references were correct. Without any intervention, the reference to Office was for 2010.
After testing with early versus late binding, it would appear the best answer to this issue is to use late binding.
Make sure you are writing to Excel in Excel compatibility mode (.xls).
I've been working intermittently on an Excel spreadsheet for a customer that does some pretty intense calculations. We implemented a security procedure using VBA... At first the requirements were relatively simple, and the overall lack of security in a spreadsheet was discussed and well understood.
Since then the customer has decided that he would like to have the sheet a bit more secure. Under normal circumstances I would simply disable the developer menu via code. Unfortunately I just recently found out that the customer, and many of his customers, are using Mac Office. (There are some customers that are even using 2008 and they found out the hard way that 2008 stopped supporting VBA)
My question is; is it possible to disable access to the Visual Basic editor in Mac Office in versions Pre 2008, and versions 2011 and after since from the research I've done so far points to a return of VBA support in Mac Office in 2011.
Unfortunately I do not have access to a Mac Office version to even really look through the application and or/test different solutions. In Windows it is possible to right click the VBA project and choose protection from the VBAProject Properties and choose "Lock project for viewing". Does this option exist and is it effective in Mac Office?
Any help/suggestions would be greatly appreciated.
I'm pretty sure you can lock projects in Mac Office the same way you can in Windows. Keep in mind that a project that has been locked in one version of Excel cannot be unlocked with a different version. So, if your customer needs to be able to unlock, they will need to use the same version of Excel you used to lock it.