is this a bug in VB 5????

Right click in your code window. Menu will show, select Toggle, Break on Unhandled errors.

I did that  but it STILL does the same thing.  This is really weird.

I did that  but it STILL does the same thing.  This is really weird.

Are you sure you have option "Break on Unhandled errors", error handler, and it still pops error dialog?

I did that  but it STILL does the same thing.  This is really weird.

I am 100% sure.

OK. Perhaps this is only with Type Mismatch errors. So, you must help vb.
DataReq = Right$(Totle, (Len(Totle) - 5))
replace with (if Datareq is integer):
DataReq = Val(Right$(Totle, (Len(Totle) - 5)))

Oops, I didn't want to give answer,
You can completely avoid error with checking:
If IsNumeric(Right$(Totle, (Len(Totle) - 5))) Then

I tested it. It is realy like you said.
this produces error dialog:
x = Right$(Totle, (Len(Totle) - 5))
but this does not:
x = (Right$(Totle, (Len(Totle) - 5)))

Funny! ()

But, I don't think this is a bug. I think this is by design. They only wanted to warn us, that we are not explicitly converting string to integer.
So, we can add Val to convert it, check with IsNumeric, or use ()

You also need to execute a RESUME to clear error handler so additional errors can be trapped. All code execute after error flag is raised until RESUME is assumed to be in error handler and error handler CANNOT have errors.

M

Well I did some testing of my own.....I think that the problem is with the fact that I have no 'resume' statement.  that you all so much!!   thanks for your help ameba...but I dont really see those results in my own testing.  Mark - come and claim u're points!!!

THANK YOU ALL WHO HELPED ME!!  =)

Hi, mark2150
Congratulations on your points, but bomax has: "Exit Sub" in his error handler. There is no need for RESUME

Every time an error is generated, its resolution remains as "pending" until a RESUME be executed, no matter which other instructions you execute (including Exit Sub).

The proper way to exit from an error-handling routine, is always thru RESUME statement.

Hello, vikiing
Lets say you have error handler:

   On error goto CriticalError ' enable error handling
   ...
   Exit sub

CriticalError:
' since error is critical, I want to exit sub
' I always use exit sub, but what is the proper way, using resume
' ameba> Exit Sub
' vikiing>

Dear Ameba:

      Your code should read like this:

    On error Goto CriticalError
     . . .

Goodbye:
    Exit Sub

CriticalError:
     . . .
     Resume GoodBye

     End Sub

Each time an error is detected, an internal flag marks the error as "Pending of resolution". Thus, if another error appears under that condition, VB will take the know action (stopping the program under control of ITS OWN error handling routine).

RESUME is the only instruction that removes the flag; thus, when another error appears, your error handling routine will activate again.

you should use err.clear after you fix your error so that the error register is empty, and do as ameba said, use
Val to convert it, check with IsNumeric, or use () , or Cint()

the goto error should be used as a last resort, where you have no choice but to catch the error like this :)

You really think additional label (Goodbye:) IS NECESSARY, even though there is no clean-up code (reseting mousepointer, clearing variables)?
"It is not nece... Don't you tell me what is nece! Of course it is not nece!" (from "High anxiety")

You *MUST* use RESUME to clear the error trap flag. ERR.CLEAR does *NOT* clear the internal state variable. It DOES remove the ERR.LINE/ERR.NUM values, but the internal state varible remains active until RESUME is executed.

There are several options on RESUME

RESUME          (no options - retry line that caused error)
RESUME NEXT (execution resumes at 1st line after error)
RESUME {target} (Execution resumes where you want.

Normally I code like:

On error Goto CriticalError
 . .

Exit Sub
' =========

CriticalError:
 . .
Resume GoodBye
Goodbye:

End Sub

This is really the only way to cleanly abort on an error.

An extra label in your code doesn't take up *ANY* resource so what is objection? The fact that it acts like a "GOTO" is inherent in the language and cannot be avoided. This is one of the reasons that GOTO will never completely die. While GOTO's are to be avoided whenever possible, this is one case where it is simply *NOT* possible to avoid it.

Vikiing is right. wford is wrong.

If you do NOT set a specific ON ERROR GOTO statement then the OS will handle the error and your program will *DIE* without doing any attempts at recovery. This is very annoying to the users as the program flames out, possibly leaving files open and losing data. So instead of "GOTO ERROR" being a "last resort" as WFORD suggests, it actually is your first line of defense.

One common error that programmers make is to assume what the error was without checking the Err.Num. This can occassionally lead to the program displaying an *erroneous* error message. Take the case of a file OPEN statement to a R/O device like a CD ROM or maybe a network directory without sufficient priveleges. The programmer may have only anticipated the cause of an error to be "Disk Full" so the program pops a "Disk Full" error when the LAN shows 387Gb of free space. This is root cause of many squirley error messages.

M

Dear Ameba:
    The label is mandatory, 'cause that's the only way to reach a point from a RESUME statement that transfers control outside error handling routine.

But, ¿what's the problem with it?. Some people think that GOTO's (or instructions like that) are bad words, and that a well-structured program must not have them.

Many times, the use of a GOTO (with good sense & judge) is the most elegant way to solve certain problems. Try to go outside a complex chained-IF structure, from the innest to the outest one. Of course, you can use a ton of flags; but ¿what about doing this?:
    If
         If
              If
                  If
                       If <certain condition> THEN OUTSIDE
                  end if
              end if
         end if
OUSTSIDE:
   end if

C'mon; that's the easiest way, withou endangering the marvelous structured way your program could be written out.

Yep. There are just some constructs that cry out for the *occassional* GOTO.

In reality the compiler will generate the occassional unconditional JMP (asm equiv of GOTO. In fact this happens every time you code a:

IF... THEN

ELSE

ENDIF

Without the implicit GOTO or JMP there is no way for the first case to reunite after the ENDIF.

M

Ok. Additional label, Err.Clear, all this works, but Exit Sub/Property/Function in error handler is also correct, and shortest way to Exit after error. If you look at MS examples (e.g. Setup1.Vbp or Visdata.Vbp) you will not see unnecessary code and labels. I am not saying they are always correct, but you can check values in Err object yourself.
After Exit Sub, error is cleared.

Private Sub Form_Click()
   Call errie
   MsgBox Err.Description
End Sub

Sub errie()
    Dim x
    On Error GoTo e
    x = 1 / 0
    Exit Sub
e:
    Exit Sub
End Sub

The cases when err will not be cleared:
1. Using Raise Method
e:
   On error goto 0
   err.Raise vbObjectError+1001
End Sub

2. Not using error handler in errie procedure
. etc

And I have nothing against GOTO!

Discussion was: is RESUME necessary, hey

Omitting the RESUME *will* bite you.

Exit SUB is *NOT* going to clear it as ON ERRORS are *GLOBAL* in scope.

The example may not show it correctly. I've seen cases where failure to have a RESUME has caused all sorts of funnies even tho EXIT SUB has been used.

M

Discussion was: is RESUME necessary, hey

Sorry for repost,
Yes, on error is global.
We are not talking about this.
If we want to talk about this, you should suggest setting On Error Resume statement in error handler, or checking caller proc, or callers' caller error handling.