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!
Related
The web store 'Open In Excel' button does not work for Mac users. Excel indicates that it is downloading some file but then nothing happens. I'm sure expected behavior is that the workbook should open and install the add-in to Excel. Here is a video showing this, on Excel v16.40 (latest version as of this writing):
https://drive.google.com/file/d/1MqlZyqhYe9MfOzJN_sjpFwyPHOn4LuPD/view?usp=sharing
I became aware of this issue because some of our customers have contacted us, asking why the add-in wasn't working. Who knows how many potential customers we have lost because they simply thought the add-in wasn't supported on their system and moved on.
Is this a problem with our add-in code? Is anyone at Microsoft aware of this issue?
All VBA projects fail to work, if you use Excel, the VBA project deleted when trying to open the workbook, if it is Access, no application works because it does not find any project.
For what I've had been researched and tested, apparently the reason is the Windows 10 update, I focused exclusively on the Office 2010, seeing macros, security, library references etc, but it seems that Windows is the problem and not the Office itself. This problem appeared 3 days ago, before that everything worked fine.
I would appreciate your help if someone else had the same problem and how you solve it.
I have Windows 10 Home, and I tried with Office 2010 (my original base Office) and then I install Office 2016 hoping to solve it, but nothing works.
Thank you very much in advance.
uninstall and install again Office 2010 with all the features (including VBA).
Macro security fully enabled
VBAProject references ok
Microsoft Visual Basic for Applications install correctly.
Install Office 2016, to try if the problem solved
Reinstall Windows 10 Home 64 to the factory line.
I have developed one trading application using VB6. In that, I have used Excel application object as below (Excel.Application).
Set xl = New Excel.Application
Set xlwbook = xl.Workbooks.Add
Dim xlsheet As Worksheet
Set xlsheet = xlwbook.Sheets.Item(1)
And, I have created the installer for that VB6's exe using Advanced Installer with prerequisites as Office 2010 Primary Interop Assemblies points to - o2010pia.msi (To enable the option to access Excel.Application).
I am unable to run installed application even installed the Office 2010 Primary Interop Assemblies. It throws Object Required error.
Note: I have googled regarding this, many of them suggested their solution for C# and/or VB .Net environment. I want it for VB6 environment.
Please help me to resolve this? Thanks in advance.
I'll summarize the comment thread as an answer. The OP has written a VB6 application that uses COM to create Excel spreadsheets. He was including the Office interop assemblies as part of his install but his code to create spreadsheets wasn't working. The reason for this is that Office was not installed on the end user computer.
The Office Interop Assemblies only give .NET applications an interface through which they can talk to the COM interface of an installed MS Office application, they don't provide Office functionality. In the OP's case he wouldn't need them as VB6 can talk directly to the COM interface of MS Office.
The OP either needs to install Office on his end user computers or generate his spreadsheets in a different way, maybe as a CSV.
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).
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....