This is similar to a question that I've asked yesterday, but I've managed to find a fair bit more information: enough to warrant a new question, I feel.
My office has recently moved to Windows 7 along with Office 2013 - with the except of Access which has stayed as 2003.
Access works absolutely fine except when I try to automate Excel. This is a feature of nearly all my applications.
When I load an old project, the reference is automatically updated to "Microsoft Excel 15.0 Object Library" - it is held as an EXE file in Program Files (x86). Note: it does not say the reference is missing.
When I try to run any code which uses early binding, it fails with the following error message: "Error in loading DLL"
I've since tried late binding by doing the following:
Dim app As Object
Dim wb As Object
Set app = CreateObject("Excel.Application")
app.Visible = True
Set wb = app.Workbooks.Add
This creates the Application, it becomes visible, a Workbook is added, but then I get the following error: "Run-time error '1004':
Application-definted or object-defined error"
If I try to access VBA in the new Workbook I get the following error: "An error occurred initializing the VBA libraries (1004)" The Workbook is loaded in "Compatibility Mode"
The above leads me to believe that the 2 applications may not be compatable, but the following is worth considering:
If I try to use early binding I don't get the Intellisense drop-downs but words like Workbook and Worksheet do auto-capitalise themselves as you would normally expect them to. The code won't compile at all if I don't have the reference set, but it does compile - and throw and error - when it is. I've since tried Word 2013 - who's Object Reference is an OLB file rather than EXE - and I get the full Intellisense features I would except, but it still throws the same error when trying to run.
In a nut shell, does anyone know if I stand any chance of having the 2 work together?
Thanks
Related
Our admins ran some MS Office 2016 updates (Build 11929.20838) and all of a sudden I noticed a few unexpected errors in one of my previously written Excel VBA macros. For example below error is popping up against any variable which I have not defined explicitly. It was not the case before and unless I had mentioned Option Explicit, I had never experienced anything like this.
Compile error:
Can't find project or library
I am also getting the same error against the following 2 statements of my code, whereas it used to run smoothly before the last Microsoft Office 2016 update.
' Against the following two declarations, the compiler is highlighting
' Date in parenthesis and quoting same error "Can't find project or library"
xMonth = VBA.DateTime.Month(Date)
xYear = VBA.DateTime.Year(Date)
' And showing same error as above against defining an Array variable like below
srchString = Array("invoice_number", "invoice_date", "Category_wise_code", "Bill To Customer", "consignees_address_long")
'And even here, it is giving the same error:
[A1].Font.Bold = True
Does anyone have any idea about these errors and how to resolve this issue? All of this quite unexpected. Let me tell you this macro has been in my use for over 4 years and I never ran into issues like these.
You will find something fishy here:
https://www.google.com/search?rlz=1C1CHZL_enGB838GB838&ei=EOInX-ibPMeusAXFw7z4Cg&q=%22ms+office+2016%22+%22july+updates%22+%22VBA%22&oq=%22ms+office+2016%22+%22july+updates%22+%22VBA%22&gs_lcp=CgZwc3ktYWIQAzoECAAQRzoICCEQFhAdEB46BQghEKABUOTJCljq_gtgg4UMaABwAXgAgAHzAogByiiSAQYyLTIuMTSYAQCgAQGqAQdnd3Mtd2l6wAEB&sclient=psy-ab&ved=0ahUKEwjo4_6J5f7qAhVHF6wKHcUhD68Q4dUDCAw&uact=5
Although not all links are opening, but Google window is briefly showing that some people are also facing macro crash situation.
Thanks for your time reading my post.
I have a vb6 program that calls Macros from an Excel file.
Until recently it worked fine (for years), but now it throws an error.
We get a runtime 438 "Object doesn't support this property or method" error.
As an example you can use this simple vb6 program:
Set App = CreateObject("Excel.Application")
Set wrkbook = App.Workbooks.Open(fileName)
App.visible = True
wrkbook.Test
The above code doesn't work anymore.
Instead, if we replace the last line with this:
wrkbook.Application.Run "ThisWorkbook.Test"
it works.
The Excel reference used for this, was "Microsoft Excel 16.0 Object Library"
This has been tested against Excel 2010, 2013, Excel365 with the same results.
Also security settings are all set off in Excel.
Before changing my entire codebase and use Application.Run, I would know why this is happening.
Also using Application.Run has also some downsides, like calling both private & public subs and exceptions thrown are not propagated back to vb6.
Are there other considerations for using Application.Run?
Did Microsoft changed something lately (Scurity update), or am I doing something wrong?
I found the problem, thanks to #UuDdLrLrSs comment.
Problem was the use of early binding.
All Excel objects should use late binding.
More specific, the workbook should be declared as object:
Dim wrkbook As Object 'New Excel.Workbook
Otherwise it cannot recognize/find your Macro method.
I'm trying to implement a bootstrap installer for my add-ins workbook, such that I can easily install the add-in for new users and send out updates. It works fine on my machine, but when having others test it, I get a runtime error when I try to call Set AI = Application.AddIns.Add(fileName:=fullPath, copyfile:=True). Specifically, the error is "1004: Unable to get the Add property of the AddIns class". I thought this was because the user needed to have "Trust access to the VBA project object model" enabled, but the error seems to occur even after they've toggled that box.
Other things I've checked:
The fullPath to the add-in is valid and the user can access the directory and the file
The user has the folder located at Application.UserLibraryPath
Any ideas?
Figured it out. It appears that the issue isn't one of permissions, but rather of whether a workbook is already open. Opening any workbook before running the Addins.Add prevented the error from occurring so I've simply added that into the program:
If Application.Workbooks.Count = 0 then Set wb = Application.Workbooks.Add()
Set AI = Application.AddIns.Add(fileName:=fullPath, copyfile:=True)
If not wb is nothing then wb.Close
Duke, perhaps it's the Trust Center settings on the recipients' machines. I have found this and may be helpful.
Best,
Danny
Check out VBA videos on ExcelVBADude on YouTube.
I have come across a strange behavior in Excel VBA when creating objects using late binding.
System information:
Windows 10 Enterprise Version: 1803
Office 365 MSO (16.0.11126.20192)32 bit
Problem description:
I have an empty Excel sheet with a macro:
Option Explicit
Sub test()
Dim ob As Object
Set ob = CreateObject("Scripting.Dictionary")
End Sub
Running this macro gives me
Run time error '429': ActiveX component can't create object
Depending on the folder where I store the macro enabled Excel file.
Folders where I can run the macro without errors
my one drive folder: C:\Users\myusername\OneDrive - MY Company Name\
all the subfolders inside this one.
Folders where errors occurs
C:\Users\myusername\
C:\Users\myusername\Desktop\
Shared network location ex: \xpto\xpto1\
C:\Temp\
C:\Q\ folder I created where I tried to mimic the same access rights as in the OneDrive folder where the macro works.
If I use early binding with the correct references the problem is not there anymore!
I tried following some steps in: https://support.microsoft.com/en-ca/help/828550/you-receive-run-time-error-429-when-you-automate-office-applications.
I am working on an app which needs to import data from Excel.
My solution is using Microsoft.office.Interop.Excel.
But I get this error when I debug:
Message=Unable to cast COM object of type
'Microsoft.Office.Interop.Excel.ApplicationClass' to interface type
'Microsoft.Office.Interop.Excel._Application'. This operation failed
because the QueryInterface call on the COM component for the interface
with IID '{000208D5-0000-0000-C000-000000000046}' failed due to the
following error: Error loading type library/DLL. (Exception from
HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY))
Below is my code:
Imports Excel = Microsoft.office.Interop.Excel
Private Sub BExcel1_Click(sender As Object, e As EventArgs) Handles BExcel1.Click
OpenFileDialog1.Filter = "Excel Files|*.xlsx; *.xls; *.xlsm"
If (OpenFileDialog1.ShowDialog() = DialogResult.OK) Then
ExcelPath1.Text = OpenFileDialog1.FileName
End If
Dim XlApp As New Excel.Application
Dim XlWorkBook As Excel.Workbook
Dim XlWorkSheet As Excel.Worksheet
XlWorkBook = XlApp.Workbooks.Open(ExcelPath1.Text)
End Sub
I have googled to find some solutions (as following), but they didn't work out:
I have repaired Office
I have repaired Visual Studio
I have used the registry editor to check the Computer\HKEY_CLASSES_ROOT\TypeLib\, but under the 00020813-0000-0000-C000-000000000046, I got only one version 1.9, it seems not like the conflict between two version?
Any ideas to fix this problem?
VS version:2017 community
Excel version:2016
Microsoft.Office.Interop.Excel version:15.0.0.0
First of all, try to run Visual Studio with the /ResetUserData command line argument. Read more about that in the Error "Unable to cast COM object..." when exporting to Microsoft Excel from Team Explorer 2008 article.
Obviously you are trying to connect to a wrong Excel version. Looks like you have some extra windows registry keys left after uninstalling an old version of Office or vice versa. Anyway, take a look at the How to solve “Unable to cast COM object of type Microsoft.Office.Interop.Excel.ApplicationClass’ to interface type ‘Microsoft.Office.Interop.Excel._Application’” blog post which describes exactly the same issue. Basically you need to find a wrong entry in the windows registry and then delete it.
BTW When you add a new COM reference to the project a missed PIA is generated automatically (if it doesn't exist any longer). So, that is a possible way to go. Also you may try to embed interop types into your own assembly like the following screenshot shows:
If you set the Embed Interop Types property to True (since .NET Framework 4.0) and the Specific Version property to False for the Office Interop assembly reference, then your code should work with any version of Excel.
However, you must compile the code with the same bitness as your Office. For a 32-bit version of Office, you must compile your code as x86, otherwise this exception can still occur on a 64-bit machine!