"ON ERROR GOTO"

Simple, yes. Reasonable? I wouldn't do it that way. IMO, and it's
only an opinion, you should break up code for one of two reasons.
Either you're doing something repetitive, which is not the case with
your code, or to break up a large amount of code into more
comprehensible chunks. In this case, the amount of code is small and
comprehension isn't enhanced by adding two additional subroutines.

OTOH, if you'd written something like (using Harlan's Dir() method):

Public Function OpenBook(fName As String, _
Optional Path As String, _
Optional ByRef wb As Workbook) As Boolean
If Dir(Path & fName) "" Then
Set wb = Workbooks.Open(FileName:=Path & fName)
OpenBook = (Err.Number = 0)
End If
End Function

And called it using something like

Public Sub Macro1()
Const MYPATH As String = "C:\dir\dir\"
If Not OpenBook("book2.xls", MYPATH) Then
MsgBox "book2.xls not found"
Else
If Not OpenBook("book3.xls", MYPATH) Then
MsgBox "book3.xls not found"
Else
MsgBox "both files are open"
End If
End If
End Sub

I could see it having utility due to coding a repetitive function
into a sub/function, especially if there were more workbooks to open
in Macro1. As it stands, it's overkill.

And, while I agreed with Harlan before, in this case and the case of
your two subs, I'm in even stronger agreement that using an error
handler is inappropriate - much simpler to handle the issue in-line.

In article ,
"Ed" wrote:

Was my code a simple and reasonable solution?:
What you need to do is seperate the 2 Open calls into
different procedures. Something like this:

J.E.,
I agree with you in a general sence, but ask you to look
back at the original request.... "If the file is not
found, look for a second file."
So, as the request was for error handleing a second error
after a first one was handeled... the only improvements
to me method would be to trap the error number and change
the handeling if the error is something othe than File
not found.
Err, if you still don't get it.... think of it as :
If there is no error: go about yer business.
If the file is not found:
Let me know the file is not there, then look for the
second file.
If you can't find the second file:
Let me know you can't find it, then give out.



-----Original Message-----
Simple, yes. Reasonable? I wouldn't do it that way. IMO,
and it's
only an opinion, you should break up code for one of two
reasons.
Either you're doing something repetitive, which is not
the case with
your code, or to break up a large amount of code into
more
comprehensible chunks. In this case, the amount of code
is small and
comprehension isn't enhanced by adding two additional
subroutines.

OTOH, if you'd written something like (using Harlan's Dir
() method):

Public Function OpenBook(fName As String, _
Optional Path As String, _
Optional ByRef wb As Workbook) As Boolean
If Dir(Path & fName) "" Then
Set wb = Workbooks.Open(FileName:=Path &
fName)
OpenBook = (Err.Number = 0)
End If
End Function

And called it using something like

Public Sub Macro1()
Const MYPATH As String = "C:\dir\dir\"
If Not OpenBook("book2.xls", MYPATH) Then
MsgBox "book2.xls not found"
Else
If Not OpenBook("book3.xls", MYPATH) Then
MsgBox "book3.xls not found"
Else
MsgBox "both files are open"
End If
End If
End Sub

I could see it having utility due to coding a repetitive
function
into a sub/function, especially if there were more
workbooks to open
in Macro1. As it stands, it's overkill.

And, while I agreed with Harlan before, in this case and
the case of
your two subs, I'm in even stronger agreement that using
an error
handler is inappropriate - much simpler to handle the
issue in-line.

In article ,
"Ed" wrote:

Was my code a simple and reasonable solution?:
What you need to do is seperate the 2 Open calls into
different procedures. Something like this:
.

Right - I understand what you were doing. It's just that I think
the implementation, using two separate subs, is not warranted. But
that's just one person's opinion - it's by no means *wrong* to do so.

Very often the solution one comes up with depends on what one
perceives the OP is looking for. Since there are so many ways of
doing things, it's often more productive to go with where the OP
seems to be comfortable rather than giving a solution that will be
incomprehesible. My comments were directed toward your more general
question, is the solution simple and reasonable. I gave you my
opinion, which you're welcome to disagree with.


In article ,
"Ed" wrote:

I agree with you in a general sence, but ask you to look
back at the original request.... "If the file is not
found, look for a second file."
So, as the request was for error handleing a second error
after a first one was handeled... the only improvements
to me method would be to trap the error number and change
the handeling if the error is something othe than File
not found.
Err, if you still don't get it.... think of it as :
If there is no error: go about yer business.
If the file is not found:
Let me know the file is not there, then look for the
second file.
If you can't find the second file:
Let me know you can't find it, then give out.

J.E.,

On the first place, I prefered Ed's theories as that
was the way I wanted it works.

In the second place, I'm interested in your theories and
Harlan too. The reason is, by combining more then one
trap code or error handler in one procedure is very
convinient, rather than putting them in seperate procedure
as an idea to avoid undesire operations by user.

But, since, Ed's responds meets my request, I suggest
you have a close look on Ed's examples given in his reply.
In that way, I hope anyone of you could figure some
comprehensive codes that runs in a single procedure.

In this case, I would like to appologize if my request as
I've posted earlier is hard to understand.

My appreciations and thanks to all of you who have
involve in this discussions.

Best wish,
Krappo.


"J.E. McGimpsey" wrote in message
...
Simple, yes. Reasonable? I wouldn't do it that way. IMO, and it's
only an opinion, you should break up code for one of two reasons.
Either you're doing something repetitive, which is not the case with
your code, or to break up a large amount of code into more
comprehensible chunks. In this case, the amount of code is small and
comprehension isn't enhanced by adding two additional subroutines.

OTOH, if you'd written something like (using Harlan's Dir() method):

Public Function OpenBook(fName As String, _
Optional Path As String, _
Optional ByRef wb As Workbook) As Boolean
If Dir(Path & fName) "" Then
Set wb = Workbooks.Open(FileName:=Path & fName)
OpenBook = (Err.Number = 0)
End If
End Function

And called it using something like

Public Sub Macro1()
Const MYPATH As String = "C:\dir\dir\"
If Not OpenBook("book2.xls", MYPATH) Then
MsgBox "book2.xls not found"
Else
If Not OpenBook("book3.xls", MYPATH) Then
MsgBox "book3.xls not found"
Else
MsgBox "both files are open"
End If
End If
End Sub

I could see it having utility due to coding a repetitive function
into a sub/function, especially if there were more workbooks to open
in Macro1. As it stands, it's overkill.

And, while I agreed with Harlan before, in this case and the case of
your two subs, I'm in even stronger agreement that using an error
handler is inappropriate - much simpler to handle the issue in-line.

In article ,
"Ed" wrote:

Was my code a simple and reasonable solution?:
What you need to do is seperate the 2 Open calls into
different procedures. Something like this: