Hi All,
I'm looking for guidance on how to retrofit into a large
AddIn the 'best' or possible uses of the Err object in providing an
information path to help track down run time errors in a 'production'
environment.

Some Background, 4 questions follow.
I was new to VBA, self taught, when the coding started, (but with
experience in other languages), and the vba error handling
seemed too complex at the time, huge mistake on my part.

The procs below are learning vehicles, which I'm just starting to play
with, but they do show the essence of my home grown method of trapping
my App's errors. They're user related, and as far as I know, Err.Number
is still 0. I scan the Status string after 'selected' calls and exit
the Sub or Function as appropriate.

Also NOT shown, is a Sub that I use,(arguments are simplified here)
Call ErrMsg_Show(Status, ErrRange, Others) which writes the sheet
location data and the message to a workbook called Trail.xls as an after
the fact record of the fleeting MsgBox contents. (Each user has one
open via reference to the "real" App data workbook.

When testing I do use Watch to spot a change in Err.Number, not a viable
method 'in production' as well as not wanting users to see the breaks
in the AddIn code.

1. Is the maximum size of Err.Description the same length as
any string variable ? (it's thousands of characters, right?)

2. The MSoft help tells me that when On Error .... is used in
a proc, that once that proc is exited, Err.Number is 0. That means to
me that I've got to 'forecast' any possible data condition where a
run time error might occur to load Err.Description with the data I want
to use later, (similar in concept to my Status method.)
Do I have this right ?

3. The samples below show a concatenation of proc names as the Err
object works its way back up the call chain to the EntryProc level.
Is this the most important thing to know is addition to the
error number and the MSoft supplied description ? Lower level
Subs and Functions are used multiple times by different entry
Subs.

4. Seems to me that since I already have the ErrMsg_Show call in
lots of places, that modifying it to process the Err object is the
least painful way to go forward.
Your thoughts are ?

Thanks,
Neal Z


Sub EntryProc()
Dim TopNum As Long, TopResult As Long, Status As String
Const Title = "Whatever"

TopNum = 2
Call ProcA(TopNum, TopResult, Status)
Call ErrMsg_Show(Status, .....)
If Err 0 Then
MsgBox Err & " " & Err.Description & ", Entry Proc"
End If

If Instr(Status,"error") 0 Then
msgbox Status,vbCritical,Title
Else If Instr(Status,"warn") 0 Then
MsgBox Status,vbExclamation,Title
end if

End Sub


Sub ProcA(InNum As Long, OutNum As Long, Status As String)
OutNum = FuncA(InNum, Status)
If Err 0 Then Err.Description = Err.Description & ", ProcA"

If Instr(Status,"error") 0 Then .....
Else If Instr(Status,"warn") 0 Then ....
End Sub


Function FuncA(InNum As Long, Status As String) As Integer
Dim lTest As Long, TestArray() As String

On Error Resume Next
lTest = UBound(TestArray) 'get error

If Err 0 Then
Status = "Error, App Text array"
Err.Description = Err.Description & ", FuncA " & Status
End If

FuncA = InNum * InNum
End Function
--
Neal Z