Run-time error 8000fff on VBA CreateObject - vba

As a follow-up to a previous post about my VBA/Rhinoscript, I'm running to a really weird "catastrophic" error when I execute the following VBA code from an Excel spreadsheet originally created in Excel 2007 that I'm now trying to run in Excel 2016:
Set Rhino = CreateObject("Rhino4.Interface")
If (Err.Number <> 0) Then
'MsgBox ("Failed to create Rhino4 object")
Set Rhino = CreateObject("Rhino4.Application")
If (Err.Number <> 0) Then
MsgBox "Failed to create Rhino4 object: " & Err.Number
Exit Sub
End If
End If
The CreateObject failing with a Run-time error 8000fff Automation error, Catastrophic failure. Checking around, people have made vague mentions of about migrating between Excel versions being a problem and to look under Tools->References, but I'm not sure exactly what I should be looking for. Does anyone know?
Thanks,
Matt

I am able to make your code work here with Excel 2010 and Rhino 4.0 SR9.
If you are not running Rhino 4.0 SR9, then I suggest you download and install this service release:
http://www.rhino3d.com/download/rhino/4.0/sr
My guess is that Rhino's COM components are not property registered (in the Windows Registry). Installing the latest service release should fix this.
Let me now if this helps.
-- Dale

Related

vbscript starting a specific profile connection in ibm personal communications

I have been given the task of converting the slower Macro Express Pro coding for IBM Personal Communications over to a VBScript/VBA version. The Macro Express Pro coding opens a predetermined profile from a specific location.
This process can take up to 30 seconds. VBScript does this in about a third of the time for a default profile (TN3270.WS). However, when we try opening the specific link highlighted in the UNET.txt file, we get this as an error:
Run-time error '440': Automation error
Here is the VBScript code we are trying to use:
Sub Main()
Dim EName
Dim autECLConnList, objConnMgr
Set objConnMgr = CreateObject("Pcomm.autECLConnMgr")
objConnMgr.autECLConnList.Refresh
objConnMgr.StartConnection ("profile='C:\ProgramData\IBM\Personal Communications\UNET REWORK.ws' connname=a")
Application.Wait (Now + TimeValue("00:00:12"))
objConnMgr.autECLConnList.Refresh
EName = objConnMgr.autECLConnList(1).Name
End Sub
The error occurs on the objConnMgr.StartConnection ("profile='C:\ProgramData\IBM\Personal Communications\UNET REWORK.ws' connname=a") line. We know we have the correct path to the profile because it's we found its location:
IBM says that if the profile name contains blanks, it "must to be surrounded by single quotes":
Can anyone provide some advice on what we're doing wrong or what we're missing?
Thanks.
I found a way of doing what I need to do. I was looking too specific into starting a PCOMM session that I didn't even think of just running the .exe file and send it parameters. Here's how I did it:
Sub Main()
Dim WShell
Set WShell = CreateObject("WSCript.shell")
WShell.Run """C:\Program Files (x86)\IBM\Personal Communications\pcsws.exe"" ""C:\ProgramData\IBM\Personal Communications\UNET REWORK.WS"""
End Sub
I'm sure this is a duplicate answer to another question out there, but most of the answers are more than a few years old and outdated. This solution is current and recently tested, so it is a more reliable source.

VBA Error 4605 This method or property is not available because the document is in modal state

Environment: Word 2016 for Mac.
The following code (which works fine in Word 2007 and 2010 for PC and Word 2011 for Mac) throws run time error 4605 at the point of the paste:
Set oSubRange = wdDoc.Sections(i).Range ' we are in a loop...
oSubRange.End = oSubRange.End - 1
oSubRange.Copy
Set wdSubDoc = Documents.Add
wdSubDoc.Activate
Set oRange = wdSubDoc.Content
oRange.Collapse (wdCollapseEnd)
oRange.PasteAndFormat (wdFormatOriginalFormatting)
My thoughts were that maybe this was a sandboxing problem, but I don't think so because I have had no issues with saving files, and this is not at the point of save anyhow. Other thoughts were that the clipboard was not copying, that perhaps there was a timing issue. I tried inserting a DoEvents() after the copy as I have seen this suggested in different error 4605 scenarios (different error though). Also tried using ActiveDocument.Range.PasteAndFormant(wdFormatOriginalFormatting) which was suggested in another forum by a MS MVP (again, different error 4605). None of these solutions worked.
So, I am stuck.

Running macros in Access 2016 from VB.net

I have a desktop application written in VB.net that runs a macro in an access. Recently we upgraded from office 2010 to office 365. Now when i run this application i get this error :
Exception that comes up
Error Image
Could not load file or assembly 'Microsoft.Office.Interop.Acces.Dao,Version =15.0.0.0...' or one of its dependencies'
Below is the code that causes the exception:
If _accessApp Is Nothing Then
_accessApp = New Application
End If
Try
If JobFolderPath.Length <= 0 Or JobFolderPath Is Nothing Then
Exit Sub
End If
If _accessApp.CurrentDb() Is Nothing Then
_accessApp.OpenCurrentDatabase(JobFolderPath & "somedb.mdb", False)
_accessApp.Run("SomeProcess")
Else
_accessApp.Run("SomeProcess")
End If
_accessApp.Quit(AcQuitOption.acQuitSaveNone)
Catch ex As Exception
Finally
_accessApp = Nothing
End Try
I even included teh Interop.Access.Dao verion 15 dll in the references for the project. Not sure if this way of running macros is obsolete in access 16. If so, what is the correct way of doing this?
Thanks in advance.
The error also says "or one of its dependencies", install the interop from the link below.
https://www.nuget.org/packages/Microsoft.Office.Interop.Excel/15.0.4795.1000
Click on "Manual Download on the right ...
Not an answer to your question, but a macro can be run without Access references with late binding:
Dim accObj = GetObject(JobFolderPath & "somedb.mdb") ' opens the file if not already open
accObj.Application.Run("SomeProcess") ' the .Application part might not be needed
accObj.Application.Quit(2) ' AcQuitOption.acQuitSaveNone = 2
or command line switches (also not tested):
Process.Start(JobFolderPath & "somedb.mdb" "/x SomeProcess")
Finally i was able to fix it by installing 'microsoft office 16.0 access database engine'(32 bit version) and adding the required dlls as COM references instead of normal dll references.

ActiveVBProject.References Error in .FullPath

We have a module that checks for machine information for troubleshooting purposes. One of the sub modules checks each reference for breaks. However for a single reference, the Microsoft Office Soap Library 3.0 it halts on an error.
We can work around it, but I'm really interested to know what is causing this error. The reference is valid, not broken. The method of the reference object simply fails for this library.
Method 'FullPath' of object 'Reference' failed
Private Sub getEachRef()
Dim ref As Variant
Dim strRef As String
'On Error Resume Next <- this allows the rest of the code to complete
For Each ref In Application.VBE.ActiveVBProject.References
frmAbout.lst_About.AddItem "[Reference] " & ref.Description
frmAbout.lst_About.List(frmAbout.lst_About.ListCount - 1, 1) = ref.FullPath <- error is here
If ref.IsBroken = True Then
frmAbout.lst_About.List(frmAbout.lst_About.ListCount - 1, 2) = "Broken Link"
End If
Next
End Sub
I run into this posting as I got the same error myself.
I've been able to trace the issue with your problem as follows:
The Error Number returned is: -2147319779
Code compiles without errors
(as mentioned in the posting) The reference is valid, not broken
(meaning that when you check your listed references, the reference(s)
is (are) not Listed as 'Missing' or if checked through VBA, is not listed as 'Broken')
I've read some other postings in other forums where even the code/VBA
application (MsAccess) actually runs without problems in 'one' PC
(PC 01) and returns the 'error' in another PC (PC 02)
I've been able to replicate this phenomena myself.
After comparing PC 01 with PC 02 you see that both PCs though may
actually have the 'same' exact version of MsAccess/Excel installed +
the same MsAccess (or Office) Service Pack installed but once you start to test each and everyone of the applied patches (this can be a
long process), you will find that some Dlls have actually NOT been replaced/patched, updated.
In my case, those affected PCs (that will NOT run the Code, thus produce an error), each had a different cause (different, not properly updated dll), thus there is NOT a 'universal' 'replace the following dlls' to repair the problem.
That said however, there is a solution (so enough of trying to explain):
1st Solution (least invasive)
Repair MsAccess/Office Installation.
When completed, re-apply latest Service Pack + all Office Updates.
This solution in 'some pcs' resolved the issue, ie. VBA Code run without problems.
If Repair MsAccess/Excel/Office Installation failed (due to Error
2424, 2425, or repair fails), then, proceed to solution Nmr. 2 (no
pun intended : D )
2nd Solution (middle group invasive)
Uninstall MsOffice completely (including all updates, Service Packs, etc.)
Will need a clean reboot after the uninstallation has completed.
After the uninstall process has completed and the PC has been rebooted, then install MsOffice again (including all updates, Service Packs, etc.)
This solution actually worked on another sub-set of affected PCs I found.
If uninstall of MsAccess/Excel/Office failed (due to the same
previous Errors 2424, 2425, or repair fails, etc), then, proceed to
solution Nmr. 3 (the nuclear option)
3rd Solution (nuclear option)
Download and Install 'Microsoft Office 2010 FixIt Tool' (or the version that may apply to your situation) https://support.microsoft.com/en-us/office/repair-an-office-application-7821d4b6-7c1d-4205-aa0e-a6b40c5bb88b?ocmsassetid=ha010357402&ctt=1&correlationid=8bfaf910-6d5f-4252-b5bb-0ed67d5d4349&ui=en-us&rs=en-us&ad=us
Run Tool to remove MsOffice 2010 completely. Once completed (PC will
need to be rebooted after the tool is finished with the cleanup/deinstallation)
Reboot PC after MsOffice 2010 (or the version that may apply to your
situation) removal has been completed (this step is very important)
Install MsOffice/MsAccess/Excel 2010 (or the version that may apply to your situation) again.
Install Language Packs (if needed).
Install the latest Service Pack ie. Service Pack 1, Service Pack 2, etc.
This solution actually fixed the 3rd group of affected PCs I had. That said however, after a 'clean' install of MsOffice, some PCs, then got a different error:
Ms Access/Excel Can't Open your previous application.
This error ONLY was found on PCs that had gone through the 3rd Option (though MsOffce and MsAccess 'seem' to work just fine and even the original 'Issue' as described in this posting was 'fixed' meaning that the code run without the Method 'FullPath' of Object Reference failed problem, then the 'new' problem was found as those 'latest' installs of MsOffice (2010 and later) seem to apply updates/service packs differently from commulative updates, vs. clean installs + latest updates/service packs.
4rth Option - Trapping the error
I'm using the same exact code as an example (see above) and insert an 'Error Trapping' Section as follows (I'm copying the entire code and pasting the completed module including the error trapping part):
Private Sub getEachRef()
On Error GoTo getEachRef_Err
Dim ref As Variant
Dim strRef As String
'On Error Resume Next <- this allows the rest of the code to complete
For Each ref In Application.VBE.ActiveVBProject.References
frmAbout.lst_About.AddItem "[Reference] " & ref.Description
frmAbout.lst_About.List(frmAbout.lst_About.ListCount - 1, 1) = ref.FullPath '<- error WAS here
getEachRef_Ressume01:
If ref.IsBroken = True Then
frmAbout.lst_About.List(frmAbout.lst_About.ListCount - 1, 2) = "Broken Link"
End If
Next
getEachRef_Exit:
Exit Sub
getEachRef_Err:
Select Case Err.Number
Case -2147319779
getEachRef_Ressume01
Case Else
MsgBox Err.Number & Err.Description
Resume getEachRef_Exit
End Select
End Sub
This code sample allows the existing code to simply 'jump' over the 'error' and continue :).
In my case, after I had some PCs with Solution No. 1, others with No. 2 and No. 3.. on any new instances, since I implemented the above 'error trapping' into the module, no more errors have been produced anywhere else.
Just to be clear, with solution No. 4, the 'error' is NOT fixed but is simply bypassed and allowed the code to continue to execute the loop.
In my case, I added some more Code into the VBA to show the 'major' version and 'minor' version of the ref.FullPath in the above code that could not be shown (so that at least I can see what was bypassed by the code).
Private Sub getEachRef()
On Error GoTo getEachRef_Err
Dim ref As Variant
Dim strRef As String
For Each ref In Application.VBE.ActiveVBProject.References
frmAbout.lst_About.AddItem "[Reference] " & ref.Description
frmAbout.lst_About.List(frmAbout.lst_About.ListCount - 1, 1) = ref.FullPath '<- error WAS here
getEachRef_Ressume01:
If ref.IsBroken = True Then
frmAbout.lst_About.List(frmAbout.lst_About.ListCount - 1, 2) = "Broken Link"
End If
Next
getEachRef_Exit:
Exit Sub
getEachRef_Err:
Select Case Err.Number
Case -2147319779
getEachRef_Ressume01
Case Else
MsgBox Err.Number & Err.Description
Resume getEachRef_Exit
End Select
End Sub

method 'comaddins' of object '_application' failed while looking for the registered COMAddins

We have this simple piece Where in we are registering an Addin and trying to find the Addin by looping through the list of Addins. This is not consistently reproducible on all the machines and we started seeing this on a client machine. We don't see anything wrong with the code either. We didn't see much on any of the forums. Please help.
When the code hits the for loop we get this error. Runtime Error -2147310770(8002801d). method 'comaddins' of object '_application' failed.
For Each oAddin In oWordApp.COMAddIns
Sub Main()
Call RegisterAddin
Dim oWordApp As New Word.Application
Dim oAddin As Office.COMAddIn
**For Each oAddin In oWordApp.COMAddIns**
If oAddin.DESCRIPTION = "TestingCom Addin" Then
oAddin.Connect = True
End If
Next
Try casting another Microsoft.Office.Interop.Word._Application variable to Word.Application, then use Microsoft.Office.Core.COMAddIn to get items in the _Application.COMAddIns collection.
I was able to fix this using the below link. Looks like the previous/latest version of Office was not uninstalled properly and was causing problems with Office 2007.
http://kb.palisade.com/index.php?pg=kb.page&id=528