How do I use vbObjectError in Err.Raise

[foxguy]

The help file says this in "Raise Method"

(both Visual Basic-defined and user-defined errors) are in the range 0–65535
.....
For example, to generate the error number 513, assign vbObjectError + 513 
to the Number property.

When I "? vbObjectError" in the immediate with I get "-2147221504". Obviously -2147221504 +513 it is not in the range 0-65535.
What am I missing?

[pike]

Miscellaneous Constants

vbObjectError -2147221504 User-defined error numbers should be greater than this value. For example:

Err.Raise Number = vbObjectError + 1000

[foxguy]

vbObjectError -2147221504 User-defined error numbers should be greater than this value. For example:

Err.Raise Number = vbObjectError + 1000

That still doesn't bring it to the range 0-65535 like help says it needs to be.

[pike]

"Required. Long integer that identifies the nature of the error. Visual Basic errors (both Visual Basic-defined and user-defined errors) are in the range 0–65535. The range 0–512 is reserved for system errors; the range 513–65535 is available for user-defined errors. When setting the Number property to your own error code in a class module, you add your error code number to the vbObjectError constant. For example, to generate the error number 513, assign vbObjectError + 513 to the Number property."

[foxguy]

Hi Pike;

That's what I'm asking about.
vbObjectError = -2147221504, so if I add 513 to it I get -2147220991, which is not in the range 0-65535.

[pike]

Two different things
error number = 1000
But the rasie the error help file you need to add the constant -2147220991
the error help file object will be -2147219991

[pike]

another tack
What are you trying to do?
the constant is added for custom errors to insure 0-65000 is not used

[pike]

hey foxguy run this

Sub tester()

On Error Resume Next
Err.Raise vbObjectError + 1, "MyAppName", "My Error"
Debug.Print Err.Description
Debug.Print Err.Source
Debug.Print Err.Number
Debug.Print Error$(-2147221503)

For Index = 1 To 20
Debug.Print Error$(Index)
Next Index
End Sub

[foxguy]

Hi Pike;
Well, I can't say that cleared anything.

So I should not "Err.Raise 513" even though it says

the range 513–65535 is available for user-defined errors

I have to "Err.Raise vbObjectError + 513" which would be equivalent to "Err.Raise -2147220991" (because vbObjectError = -2147221504), even though it says

Visual Basic errors (both Visual Basic-defined and user-defined errors) are in the range 0–65535.

It seems to me that those 2 conclusions are mutually exclusive.

Your questions

What are you trying to do?

I'm setting up a global error trapping system and want to assign error numbers that are specific to my applications

the constant is added for custom errors to insure 0-65000 is not used

That's my first thought except for this:

Visual Basic errors (both Visual Basic-defined and user-defined errors) are in the range 0–65535.

If I ignore this part of the help for Raise, then everything makes sense, but I can't find a reason to ignore it.

[pike]

hmmm.

Sub tested()
On Error GoTo errorhandler
txt = 1 / 0
Exit Sub
errorhandler:
Err.Raise vbObjectError + 11, "MyAppName", "You stuffed up big time"
End Sub
Sub tester()
On Error GoTo errorhandler
txt = 1 / 0
Exit Sub
errorhandler:
If Err.Number = 11 Then
Err.Raise 11, "MyAppName", "You stuff up big time"
End If
End Sub

you can make the help file ecy..

[foxguy]

HI Pike;

you can make the help file ecy..

I don't know what ecy is.

Sounds to me like you're reaching the same conclusion I have.
We can use just about any # we want. It's a good idea to use negative #s for our own use, because the positive #s already have a description attached to them (although we can override the built in description).
And an easy way to make sure that it's negative is to add it to vbObjectError.

[pike]

Thats about it counterintutive
or just use a msgbox

msgBox Err.Description & Chr(10)& Chr(10) & "This is what you need to do"& Chr(10)& Chr(10) & "Step 1./Has any one seen you ", vbcritiacl, "A Big Big Error has ocurred"

[Andy Pope]

The constant is designed to keep your error codes away from those already assigned in VBA.

If you really want to show the use an error code of 1 or 2 etc then you need to handle that.

Const ERR_ANDY_PROBLEM_1_CODE As Long = vbObjectError + 1
Const ERR_ANDY_PROBLEM_2_CODE As Long = vbObjectError + 2
Const ERR_ANDY_PROBLEM_1_DESC = "Error Problem 1"
Const ERR_ANDY_PROBLEM_2_DESC = "Error Problem 2"

Sub x()
    
    On Error GoTo ErrTest
    
    Err.Raise ERR_ANDY_PROBLEM_1_CODE, "Routine X", ERR_ANDY_PROBLEM_1_DESC
    Err.Raise ERR_ANDY_PROBLEM_2_CODE, "Routine X", ERR_ANDY_PROBLEM_2_DESC
    
    Exit Sub
    
ErrTest:
    Select Case Err.Number
    Case ERR_ANDY_PROBLEM_1_CODE
        MsgBox "Err: " & ERR_ANDY_PROBLEM_1_CODE - vbObjectError & vbLf & Err.Description, vbExclamation, Err.Number
    Case ERR_ANDY_PROBLEM_2_CODE
        MsgBox "Err: " & ERR_ANDY_PROBLEM_2_CODE - vbObjectError & vbLf & Err.Description, vbExclamation, Err.Number
    Case Else
        MsgBox "Err:" & Err.Number & vbLf & Err.Description
    End Select
    
    Resume Next
    
End Sub

Although you may argue it is easier for a user to report they encounter error number 1 rather than -2147221503 the really important thing is you/your code knows what the value means.

[foxguy]

Hi Andy;

So I should just ignore the part in the help file that says:

Visual Basic errors (both Visual Basic-defined and user-defined errors) are in the range 0–65535.

and

the range 513–65535 is available for user-defined errors

I had pretty much figured that out myself, but I still feel uneasy about it. I guess I'm just looking for someone to agree with me.

[Andy Pope]

This says the same thing
http://visualbasic.freetutes.com/lea...son11/p14.html

And this explains the negative value, unsigned integers.
http://books.google.co.uk/books?id=g...terror&f=false

[foxguy]

Thanks Andy. It's nice to see that someone agrees with my conclusions.

[macarius]

use "(vbObjectError + <<your err number>>)" to create the long value and "Err.Number And &HFFFF&" to return the value of "<<your err number>>"

"&HFFFF&" masks the upper bits -- make sense?

[Warbe]

This question had been raised many times. However, I found most of the replies were technically perfect but not very practical. The use of vbObjectError avoids any conflicts between programmed (application) error numbers and VB error numbers, simply by turning a positive application error number into a negative one. Unfortunately, any error message not considering negative error numbers will report values like -21472215.. which gives you a headache were in the code the error may have occurred. I solved the problem by two things:
1. My error messages always report the module.procedure as error source
2. My programmed errors look like

Err.Raise AppErr(n), ErrSrc(PROC), .....

whereby n is any positive number starting with 1 in every procedure. My error message translates any negative error number back into its original positive number and clearly indicates it as Application Error n distinguishing it from any VB Error n. For this I use the (project global) function:

Public Function AppErr(ByVal lNo As Long) As Long
' -----------------------------------------------
' !! For use with Err.Raise AppErr() !!
' Ensures that programmed (application) error
' numbers never conflict with VB error numbers.
' Translates the positive number (lNo) into a VB
' conforming application error number which is
' a negative value.
' In return, translates a negative error number
' back into an Application error number.
' The latter is the reason why this function
' must never be used with a true VB error number.
' -----------------------------------------------
    If lNo < 0 Then
        AppErr = lNo - vbObjectError
    Else
        AppErr = vbObjectError + lNo
    End If
End Function

and in each module:

Private Function ErrSrc(ByVal s As String) As String
    ErrSrc = "mTest" & "." & s
End Function

Anyone interested in my common global error handling approach may download ErrHndlr.xlsm which includes demo and test module.
I think it had become one of the most elaborated solutions you may find.