Rory has already told you what the main problem with your code is.
I would recommend a slightly different approach to what you are trying to achieve.
Please note that xlDown
should be avoided as much as possible. Consider the scenario where there is data only in cell A1
. In such a case xlDown
will select the entire Col A. The alternative is to find last row in Col A which has data and then create your range.
With ws
'~~> Find Last Row in Col A and then create the range
'~~> oXL is the Excel Application
If oXL.WorksheetFunction.CountA(.Cells) <> 0 Then
lastrow = .Cells.Find(What:="*", _
After:=.Range("A1"), _
Lookat:=xlPart, _
LookIn:=xlFormulas, _
SearchOrder:=xlByRows, _
SearchDirection:=xlPrevious, _
MatchCase:=False).Row
Else
lastrow = 1
End If
Set Rng = ws.Range("A1:A" & lastrow)
End With
And declare this at the top
Const xlPart As Long = 2
Const xlFormulas As Long = -4123
Const xlByRows As Long = 1
Const xlPrevious As Long = 2
And if you are sure that there will always be data in Col A then you can try this as well
lastrow = ws.Range("A" & ws.Rows.Count).End(xlUp).Row
Set Rng = ws.Range("A1:A" & lastrow)
And declare this at the top
Const xlUp As Long = -4162
title | keywords | f1_keywords | ms.prod | ms.assetid | ms.date |
---|---|---|---|---|---|
Application-defined or object-defined error |
vblr6.chm1011299 |
vblr6.chm1011299 |
office |
4c1ea0e8-e6f6-a960-eb13-b4dfc2bf96fe |
06/08/2017 |
This message is displayed when an error generated with the Raise method or Error statement doesn’t correspond to an error defined by Visual Basic for Applications. It is also returned by the Error function for arguments that don’t correspond to errors defined by Visual Basic for Applications. Thus it may be an error you defined, or one that is defined by an object, including host applications like Microsoft Excel, Visual Basic, and so on. For example, Visual Basic forms generate form-related errors that can’t be generated from code simply by specifying a number as an argument to the Raise method or Error statement. This message has the following causes and solutions:
-
Your application executed an Err.Raisen or Errorn statement, but the number n isn’t defined by Visual Basic for Applications. If this was what was intended, you must use Err.Raise and specify additional arguments so that an end user can understand the nature of the error. For example, you can include a description string, source, and help information. To regenerate an error that you trapped, this approach will work if you don’t execute Err.Clear before regenerating the error. If you execute Err.Clear first, you must fill in the additional arguments to the Raise method. Look at the context in which the error occurred, and make sure you are regenerating the same error.
-
It may be that in accessing objects from other applications, an error was propagated back to your program that can’t be mapped to a Visual Basic error.
Check the documentation for any objects you have accessed. The Err object’s Source property should contain the programmatic ID of the application or object that generated the error. To understand the context of an error returned by an object, you may want to use the On Error Resume Next construct in code that accesses objects, rather than the On Error GoToline syntax.
List trappable errors for the host application
In the past, programmers often used a loop to print out a list of all trappable error message strings. Typically this was done with code such as the following:
For index = 1 to 500 Debug.Print Error$(index) Next index
Such code still lists all the Visual Basic for Applications error messages, but displays «Application-defined or object-defined error» for host-defined errors, for example those in Visual Basic that relate to forms, controls, and so on. Many of these are trappable run-time errors. You can use the Help Search dialog box to find the list of trappable errors specific to your host application. Click Search, type Trappable in the first text box, and then click Show Topics. Select Trappable Errors in the lower list box and click Go To.
For additional information, select the item in question and press F1 (in Windows) or HELP (on the Macintosh).
- Remove From My Forums
-
Question
-
Hello all,
I have an access application that allows for the user to Save the current form record and also generate an email. After clicking the command button they are asked to allow or deny the event.
If the user clicks Deny they receive the error message «Run-time error ‘287’: Application-defined or object-defined error»
The user can then either click End or Debug. If they click End there isn’t an issue. If they click Debug the VBA debugger is opened and the code is displayed. This could result in the users making changes to the application code and cause it to break
further.How can I fix the VBA code so it works without this error appearing?
The code is below and attached is the error message and the point the debugger picks up the error. Any assistance is appreciated.
Private Sub Command75_Click() Dim stId As Integer Dim db As Database Dim rs As DAO.Recordset Dim appOutLook As Outlook.Application Dim MailOutLook As Outlook.MailItem Dim stText As String Dim stDefect As String Dim stGkOrder As Long '==Save the current record If Me.Dirty Then Me.Dirty = False Set appOutLook = CreateObject("Outlook.Application") Set MailOutLook = appOutLook.CreateItem(olMailItem) '==Set db = CurrentDb() '==Set rs = db.OpenRecordset("dbo.NonConfData") stId = Me.Id stDefect = Me.Combo45.Column(1) stGkOrder = Me.GKOrderNum stText = "NonConformance IR #" & " " & "Defect Category:" & stDefect & " " & "Against Order#" & stGkOrder With MailOutLook .BodyFormat = olFormatHTML .To = "capateam@company.com" ''.cc = "" ''.bcc = "" .Subject = "NonConformance Generated IR #" & stId .HTMLBody = stText .Send End With '==rs.Close
Keith
-
Edited by
Friday, December 27, 2013 9:13 PM
-
Edited by
Answers
-
You need error handlers to properly manage errors. Users should never see the End/Debug dialog.
Here’s the basics:
Function YourFunction() On Error Goto Error_Proc ' all your usual code goes here' Exit_Proc: 'this is your exit portion' 'all exits will be directed here' 'use this to clean up any open objects' Exit Function Error_Proc: 'this is your error handler' 'with the On Error statement at the top,' 'any errors jump to the specified label' '' 'check errors:' Select Case Err.Number Case 287: Resume Exit_Proc 'ignore the error' Case Else: MsgBox "Error encountered: " & Err.Description Resume Exit_Proc 'display a message then exit' End Function
This should be standard for pretty much every procedure. Tools like the invaluable mz-tools (www.mztools.com) let you customize your handler and add it to a procedure with the click of a button.
Do a google search for VBA error handling for more info, but the above is fully sufficient. There’s more complex global handlers that can log errors, notify developers, etc, but this is all you really need.
Cheers
Jack D. Leach (Access MVP)
UtterAccess Wiki: (Articles, Functions, Classes, VB7 API Declarations and more)
Dymeng: blog |
Services-
Edited by
Jack D Leach
Saturday, December 28, 2013 3:04 PM
changed error number from 291 to 287 -
Marked as answer by
Keith732
Friday, January 3, 2014 2:11 PM
-
Edited by
-
Your Access instance probably has the option «Breal on All Errors» selected.
In the code window, use the Menu command Tools / Options… / General tab and chgane the error-trapping option to «Break on Unhandled Errors» and then try your code again.
Note: the code you posted WILL display the error message when an error occurs UNLIKE Jack’s suggested code (which trap all errors and display the error message for all errors EXCEPT error 287).
Van Dinh
-
Marked as answer by
George Hua
Friday, January 3, 2014 9:48 AM
-
Marked as answer by
|
|