Some VBA code no longer works for me, when creating COM objects from standard libraries such as Microsoft Scripting Runtime or Microsoft Xml, v6.0. I get an error on the line of instantiation, the error is code
80004021(-2147467231) and error description is Automation error The operation attempted is not supported. But I can create C# code with interop references to these libraries perfectly fine. I had an Windows 10 update KB4586781 two days ago.
The code fails in both Excel VBA and Word VBA. Anyone else with similar issues?
Sub TestCreate_Scripting_Dictionary()
'* THIS CODE FAILS !!!!
Dim lateBound As Object
Set lateBound = VBA.CreateObject("Scripting.Dictionary") '<=== FAILS 80004021
' ... Automation error The operation attempted is not supported.
'* Tools->References->Microsoft Scripting Runtime
Dim dict As Scripting.Dictionary
Set dict = New Scripting.Dictionary '<=== FAILS 80004021
' ... Automation error The operation attempted is not supported.
End Sub
Sub TestCreate_MSXML2_DOMDocument60()
'* THIS CODE FAILS !!!!
'* Tools->References->Microsoft Xml, v6.0
Dim xml As MSXML2.DOMDocument60
Set xml = New MSXML2.DOMDocument60 '<=== FAILS 80004021
' ... Automation error The operation attempted is not supported.
End Sub
UPDATE: I was meaning to reinstall but it went away without any intervention. Odd.
Related
I'm trying to get clipboard data through this lines:
Sub GetClipboard()
Dim objData As New MSForms.DataObject
Dim strText
objData.GetFromClipboard
strText = objData.GetText()
MsgBox strText
End Sub
I get the error:
"User-Defined type not defined"
While "Microsoft Office 16.0 Object Library" is selected in Tools> Reference!
Appreciate any help on this.
It looks like you are missing the correct reference.
In this case for the MSForms namespace you need the Microsoft Forms Object Library (e.g. Microsoft Forms 2.0 Object Library reference).
On my installation of Office 2016 I do not have this library that I could reference. But as stated here (https://wellsr.com/vba/2015/tutorials/vba-copy-to-clipboard-paste-clear/) there are problems since Windows 8/10 anyway. The solution is to use the Windows API directly. Which should work on Windows 7 and newer.
In the first link there is an example only for setting data to the clipboard. You asked for retrieving data so a quick internet search revealed this example code which is described as working on Windows x86 and x86_64 and supports setting and getting data from the clipboard (https://francescofoti.com/2013/12/share-the-clipboard-with-vba-and-the-windows-api/).
I have tested the code from the second link to retrieve a string from the clipboard and it worked. I had to fix a minor thing. The Application object on my Office installation does not have a member called hWndAccessApp. One has to replace it with the default hwnd member:
Application.hWndAccessApp
replaced with:
Application.hwnd
You need below
set objData = New MSForms.DataObject
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 have following code, which check-out (locks) file with ID = 1, in Sharepoint Library Document application:
Sub LockAccessDatabase()
Dim context As New ClientContext("https://web.page.net/sites/MySite/")
Dim mylist As List = context.Web.Lists.GetByTitle("MyLibraryDocument")
Dim listItem As ListItem = mylist.GetItemById("1")
Dim file As File = listItem.File
file.CheckOut()
context.Load(file)
context.ExecuteQuery()
End Sub
It is using references:
Microsoft.SharePoint.Client
Microsoft.SharePoint
This code is working well, in Visual Studio, but then I need to use it in Excel application (translate to VBA). Unfortunatelly, when I try to import library to Excel Vba, I got following error:
For what I found - I need to declare necessary functions in the code. I need some support information how to do that. How can I know which functions I need to declare? How can I find necessary functions?
I've spent so much time searching for this solution, and now it seems that I stuck just before finish.
If I Run
Sub test()
Dim Template_Excel_Instance As excel.application
Set Template_Excel_Instance = CreateObject("excel.application")
End Sub
my code breaks with an error "Automation Error, Library not registered"
If I run
Sub test()
Dim Template_Excel_Instance As object
Set Template_Excel_Instance = CreateObject("excel.application")
End Sub
It runs fine. Is there any way to fix this? Reason I ask is that this issue only affects one PC, despite having the same references as all other PCs. The first error is not coming up anywhere else
Does that PC have a different version of Excel?
The problem is with As Excel.Application. If you don't have the appropriate reference defined, then the VBA compiler will not recognise the type. Yes, VBA does have a compilation step. If you do have the reference defined, then this is sensitive to the application version (just the major part of the application version I think), so is therefore inherently non-portable.
In your latter example, you are using late binding, so only COM object registration is required, not any specific library to be added to your project. For portability, this is the way to go.
Firstly, have you tried repairing the install?
Secondly, is there a reason you are instantiating a second instance of Excel?
Thirdly, let's get a grip on what is happening, please run this code and report back.
Option Explicit
Sub TestWhatVersionDoesCreateObjectReturn()
Dim obj As Object
Set obj = CreateObject("Excel.Application")
Debug.Print obj.Version
End Sub
Sub TestWhatOtherVersionsAreCreatable()
Dim lLoop As Long
For lLoop = 7 To 16
Dim obj As Object
Set obj = Nothing
On Error Resume Next '///set break on unhadnled errors
Set obj = CreateObject("Excel.Application." & CStr(lLoop))
On Error GoTo 0
If Not obj Is Nothing Then Debug.Print obj.Version
Next
End Sub
Also, look for multiple installations of Excel. The code at this blog page will read your registry and write the results to an Excel worksheet. You say you have repaired the install but there might be other Excel installations interfering. The code in that blog will highlight multiple Excel installs.
Ok, from your feedback you say all the Excel libraries version return 14, implying no multi version installs. Hmmm, we ought to consider that actually the library that error is complaining about isn't Excel but a dependency.
Other possible leads
Social MSDN - automation error. Library not registered - solved by cleaning registry of legacy "Microsoft.Office.Interop.Excel" keys
We share our Excel Macro - MS Access project with our client.
They don't know to select the 'Microsoft ActiveX Data Objects x.x Library' from the Tools --> References.
Any code to automatically update MS ADO library settings?
Note: In Office we are using MS 2010. I think the client's office is using Micorsoft XP.
I suggest above to use late binding, but you could do something like this (my code exactly as used in PPT 2010, should be easy enough to adapt to Access but I do not ever use access).
You may need to change the ADODBReference constant for use in XP. Or you could add another constant and a logic check to see what Application.Version and load from the appropriate destination path.
Public Const ADODBReference As String = "C:\Program Files (x86)\Common Files\System\ado\msado15.dll"
Sub PPT_AddRefToADODBLibrary()
'Adds a programmatic reference to ADODB library if one doesn't already exist
'ADODBReference is a public const refers to Microsoft ActiveX Data Objects 6.0 Library
If Not PPT_RefExists(ADODBReference, "Microsoft ActiveX Data Objects 6.0 Library") Then
Application.VBE.ActiveVBProject.References.AddFromFile _
ADODBReference
Else:
'Already installed
End If
End Sub
The sub above calls on this custom function, which first iterates the active References
Function PPT_RefExists(refPath As String, refDescrip As String) As Boolean
'Returns true/false if a specified reference exists, based on LIKE comparison
' to reference.description.
Dim ref As Variant
Dim bExists As Boolean
'Assume the reference doesn't exist
bExists = False
For Each ref In Application.VBE.ActiveVBProject.References
If ref.Description Like refDescrip Then
PPT_RefExists = True
Exit Function
End If
Next
PPT_RefExists = bExists
End Function
Trying to simply turn it on with a code like this:
Application.VBE.ActiveVBProject.References.AddFromFile "C:\Program Files (x86)\Common Files\System\ado\msado15.dll"
you may come across three problems: it is already installed, earlier version is installed, the file path is invalid. So my logic is as follows:
Code loops through all refs and checks if ref to Microsoft ActiveX Data Objects 6.0 Library is installed.
If not installed, then it tries to install it with error handling.
If failure will occur, it means that either earlier version i.e. Microsoft ActiveX Data Objects 2.8 is installed (could be checked while looping) or the file path is invalid.
Code:
Sub AddReferenceMicrosoftActiveXDataObjectsLibrary()
Const MyRefPath As String = "C:\Program Files (x86)\Common Files\System\ado\msado15.dll"
Dim ref As Variant
Dim IsInstalled As Boolean: IsInstalled = False
For Each ref In Application.VBE.ActiveVBProject.References
Debug.Print ref.FullPath
If ref.FullPath = MyRefPath Then IsInstalled = True
Next
If IsInstalled = False Then
On Error GoTo err:
Application.VBE.ActiveVBProject.References.AddFromFile MyRefPath
On Error GoTo 0
Debug.Print "Just installed"
Exit Sub
Else
Debug.Print "Already installed"
End If
Exit Sub
err:
MsgBox "Probably earlier version of Microsoft ActiveX Data Objects is already installed or other error occurred"
End Sub
I think late binding is the only way.
I made an Excel-based application for my office, and every time i prepare new version there is about 10% of users I have to visit to add references.
I found out, that since these computers have different Windows versions, for some dll's there is no version which would exist on each computer.
This makes adding references from code more difficult and I do not want to use late binding.
Thats a pity - most of the dll's functionality I use is compatible among all versions.