This is a weird error. It only occurs on some machines here, but not all of them. Furthermore, I researched this website and there are no solutions that I can see that cover this.
I receive this error when attempting to run some VBA code in an excel document.
The line of code it occurs in is in the
Private Sub UserForm_Initialize()
event.
The line of code is:
Set objTest = CreateObject("MTRClassLibrary.MTRTestComClass")
As I mentioned previously, the code only errors out on some of the machines here but not all of them.
It is not clear where and how the objTest instance is declared in the code. Also, you need to make sure the corresponding object is registered on the problematic machine. The CreateObject can't locate applications with ProgId passed as a parameter. Try to check the Windows registry for the string passed.
See Object variable not set (Error 91) for all possible cases.
Related
Background:
Recently, a macro I use via VBA (in Excel) to run a script has stopped working; this subroutine worked for the previous six years. This is on a work device in which I do not have full admin privileges. The script file is stored on a network drive which I have access to, and can open and double-click to execute.
I have read from multiple sources, each not having an answer (including here on SO), that people have begun to see RTE5 when using Shell(), which may be related to security settings from the administrator.
One suggestion was to use use ShellExecute, which I have not had luck using.
Issue:
I receive RTE5 (invalid procedure call or argument) on the line for Shell() within the below code.
Question:
Has anyone had this same issue and been able to resolve said issue? Please indicate how you resolved.
Code:
'To open file, which previously worked:
Dim Loc As String
Loc = "Z:/filename.bat"
Call Shell(Loc, 1)
'Attempt at using ShellExecute, which gives Network Access error
Dim Loc As String
Loc = "Z:/filename.bat"
Call CreateObject("Shell.Application").ShellExecute(Loc, 1)
I have the following line of vba code in a subroutine:
filter_values_Lrow = Range("C"& Rows.count).End(xlUp).Row
contracts_products = Application.transpose(Application.WorksheetFunction.Unique(Range("B2:B"&filter_values_Lrow)).
This code works well in the "normal environment", whilst when I run this code on my virtual machine it produces an 438 error: Object doesn't support this property or method. Does anyone know why this could be the case? The excel file is able to be opened and other mutations on that file are possible.
Kind regards.
I am on Day one in learning Excel Macros. As per the tutorial I recorded the macros and tried to run it. (I have used the same file that they have provided in the tutorial and it is a .csv file)
But it showing me the following Error
Runtime Error
Invalid Procedure call or Argument
When I tried to debug it is showing as follows:
Need Help
-Thanks
You can set the CommandType property only if the value of the QueryType property for the query table or PivotTable cache is xlOLEDBQuery, which is enum 5.
This is not the case for your query. In fact, that line doesn't even exist in the source code. Perhaps you attempted to merge scripts? If so, be careful when merging connection code that the types are the same.
If you add in a debug line to get the QueryType
Debug.Print .QueryType
.Name = "receipts"
you will get the enum 6 back. You can look this up using the object explorer:
As would be expected from the connection specification:
ActiveSheet.QueryTables.Add(Connection:="TEXT;
I have a VB6 application that, despite everything manages to work on lots of systems, including the numerous Windows 7 x64 systems.
On most of them, the windows dialogs accessed through COMDLG32.OCX work just fine. However, on one particular system, this doesn't work at all. Some forms, when attempting to show the "Open" (or "Save") dialog causes an exception:
Run-time error '32765'
The common dialog function failed during initalization. This error often occurs when insufficent memory is available
Although some other forms that use it simply never show the dialog box at all. Needless to say, memory is not an issue. Microsoft have a kb article on the error where they say:
You have a Microsoft Visual Basic 6.0 program that runs on a Terminal Server, the program uses the Common Dialog control to open a file, and the following conditions are true:
The user is using a roaming profile.
There is a policy to delete the roaming profile when the user logs off.
When these conditions are true, you may receive [the error quoted above]
The conditions mentioned are not true - this is all through the (only, local) user on the system. The suggested solution involves calling the relevant API calls directly.
Reluctant to implemenet the pile of code suggested in every form relevant, I found a class already built for the purpose - CDlgEx. While this works fine on all the computers where the OCX also works fine, on the system which has problems, whenver this line is reached:
RetValue = GetOpenFileName(OFN)
where
Private Declare Function GetOpenFileName Lib "comdlg32.dll" Alias "GetOpenFileNameA" (pOpenfilename As OPENFILENAME) As Long
and OFN is of the private type expected by the function, nothing happens. No dialog box appears, and the program simply moves on to the next line.
Further testing has shown that this only happens when running from the IDE. Running from a compliled executable, everything is fine.
Had the exact same problem. Grab the cCommonDialog class from the following link and add it to your project.
https://github.com/ziggythehamster/ignitionserver/blob/master/vbtracer/cCommonDialog.cls
You can then do something like this in your code
Private Sub Command1_Click()
Dim commonDialog As New GCommonDialog
Dim fileName As String
commonDialog.VBGetOpenFileName fileName
MsgBox fileName
End Sub
I am (unfortunately) developing an application in Excel 2000 VBA. I believe I have discovered that any error raised within a Custom Class property, function, or sub debugs as if the error were raised at the point in the VBA code where the property is called. That is, the VBE debugger does not take me to the point in the Class property where the error occurred, but instead where the property was first entered (from a Module Sub or Function, e.g.) This makes it frustrating to develop anything more than the most shallow OO Excel 2000 VBA code since I have to step line-by-line through every Class method to discover the instructions causing an error.
Am I missing something or is this a known bug I have to deal with in Excel 2000? Has this been fixed in 2003 or 2007?
Example code:
'''''''''''''''
'In Module1:
Public Sub TestSub1()
Dim testClass As Class1
Dim testVariant As Variant
Set testClass = New Class1
testVariant = testClass.Property1 'Debugger takes me here...
End Sub
''''''''''''''
' In Class1
Property Get Property1() As Variant
Err.Raise 666, , "Excel 2000 VBA Sux!" 'But error is actually thrown here.
End Property
For Office 2003 you will get this behaviour when the debugger is configured to break on unhandled errors (the default configuration).
If you want it to break on the Err.Raise line, you need to configure it to break on all errors (Tools/Options/General/Error Trapping/Break on All Errors).
I believe it's the same for Office 2000 but don't have a copy to check.
This page is a very good resource on error handling in VBA:
Error Handling and Debugging Tips and Techniques for Microsoft Access, VBA, and Visual Basic 6
This "feature" is the same in Excel 2003 and I'd be surprised if it's different in 2007.
The same still holds true in Excel 2010 - that's where I met this behaviour.
To quote Chip Pearson's site:
There is absolutely no reason to use an error trapping setting other than Break In Class Module.
His description of the difference between the error modes:
When you are testing and running your code, you have three error trapping modes. The first is Break On All Errors. This will cause the debugger to open if any error occurs, regardless of any On Error handling you might have in the code. The second option is Break On Unhandled Errors. This will cause the debugger to open if the error is not handled by an existing On Error directive. This is the most often used option and is the default setting. The third option, Break In Class Module is the most important and least used. It is not the default error trapping mode, so you have to set it manually.
The Break In Class Module is the most important because it will cause the debugger to break on the line of code within an object module that is actually causing the problem. The Break In Class Module setting is in the Options dialog accessible on the Tools menu. It is on the General tab of the Options dialog, as shown below.