Why doesn't this work.

[Fred Buffington]

I first made this program with PBCC and contools and
it worked fine. I then made it a dll in PBdll 6.0 and
had the following problem (I was able to get around it
so I'm just curious more than anything).

There is no dialog - just a collection of msgboxes and
input boxes but the problem is on an on error goto.
The error happens on the mkdir (which has already been
made previously). It never seems to go to the ALREADYMADE
error routine (i put a msgbox at the beginning to see).
As i said, I got around it by using a on error resume next.
(I hope this shows up indented - I did post it that way)
Thanks
.
.
.
ON ERROR GOTO ALREADYMADE
ecode%=1
MKDIR whatever
aftermkdir:
ecode%=2
KILL whatever
afterkill1:
.
.
ALREADYMADE:
select case ecode%
case 1
RESUME aftermkdir
case 2
RESUME afterkill1
.
.
end select
close
exit sub
'just in case


------------------

[Michael Meeks]

Fred

RESUME aftermkdir look's incorrect to me.
The reason is because you have already established
how your error routine is to work, by telling it
to (On Error Goto ALREADYMADE), you didn't say
(On Error Resume Next)!

Here's a quick fix, but you could make this look
much better! Please bear in mind, I prefer not to
use the Goto Statements, but that's usually the
programmers point of view!

ON ERROR GOTO ALREADYMADE
ecode%=1
MKDIR whatever
aftermkdir:
ecode%=2
KILL whatever
afterkill1:
.
.(exit function code here)
Goto FinishUp
.
ALREADYMADE:
select case ecode%
case 1
Goto aftermkdir  <-----
case 2
goto afterkill1  <-----
.
.
FinishUP:
end select
close
exit sub

Hope this helps
Mike


------------------
mwm

[Fred Buffington]

Thanks Michael for your input. I have used gosub's within an
error routine before but only as a way to get something for
the error routine a display or whatever. I have always used
resume linelabel and thought that in error routines it was
required at least to "resume" the program (since the resume
next statement is not valid in pbcc/pbdll). Like i said I did
get around it by using on error resume next.

Also, it works flawlessly in PBCC with the resume statements in
"alreadymade" routine.


------------------

[Frank Kelley]

Here's a simpler way to handle this, direct from a PB/DLL program I'm working on:

SUB CreateDir(BYVAL Dirname AS STRING)
   LOCAL x&
   MKDIR Dirname
   x& = ERRCLEAR
END SUB

If the directory already exists, the error is cleared with no jumping or resuming. (Also works in PB/CC).

Frank

------------------

[Michael Meeks]

Thanks Frank,

That's one I didn't know!
Learn something new everyday!

Mike


------------------
mwm

[Fred Buffington]

Thanks Frank.
I guess the same logic would work for KILL too would it not ?
(I have several KILL statements after the MKDIR statement)

------------------

[Lance Edmonds]

Originally posted by Michael Meeks:
RESUME aftermkdir look's incorrect to me.
The reason is because you have already established
how your error routine is to work, by telling it
to (On Error Goto ALREADYMADE), you didn't say
(On Error Resume Next)!
Here's a quick fix, but you could make this look
much better! Please bear in mind, I prefer not to
use the Goto Statements, but that's usually the
programmers point of view!

Michael, your advice is a little off I'm afraid. From the incomplete snippet of coide, the error trap does appears to be constructed correctly as it does indeed use a manditory RESUME statement.

All ON ERROR GOTO error traps must be terminated by a RESUME statement. When an error is encountered, execution jumps to the error trap where an implicit ON ERROR GOTO 0 is performed. When the RESUME statement executes, the original error trap operation is restored. By using a GOTO instead of a RESUME statement, you foul the operation of the code leaving the error trap useless after the 1st error occurs.

In this situation a ON ERROR RESUME NEXT would be the best approach as no direct action seems to be taken in the event that one of the MKDIR or KILL statements fails. However, the snippet was not complete enough to be 100% sure of the cause of Fred's problem. His snippet does not include any code that "jumps over" the error trapping code, thus running the risk of executing the error trap code when there was no runtime error.

Franks code simply emulates a ON ERROR RESUME NEXT by wraping the problematic code into a separate Sub. In this simplistic situation, this is really an overkill.

Please be sure to study the chapter "Errors and Error Trapping" in the help file.



------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Frank Kelley]

In this simplistic situation, this is really an overkill.

Not when your program is creating/checking for 13 subdirectories.

------------------

[Fred Buffington]

Thanks Lance for your confirmation of "on error" routines.

And there was no chance of it going to alreadymade: routine
by mistake. After this group of statements is passed an
ON ERROR GOTO ERROR_ROUTINE is stated to resume the sub's main
error handler. I guess the use of the CreateDir sub and anything
like it might afford some help in debugging that on
error resume next might not. Other than that I agree that I see
little use for it in my situation anyway.

I just thought it strange that it seemed to work fine in cc
(as an exe when called) but not from the dll version. they are
identical except having a inputbox function to emulate inputbox$
and a msgbox funtion to emulate msgbox in the cc version.




------------------