Mike;

Well, I came up with something similar that seems to work OK. I am using VFE, and it returns integers from most methods indicating success, failure, trapped error, untrapped error etc. I added a custom property to my class (lCannotCopyFiles). I set it to true in my error handler if I get an error 3 in the specific method. Then after my COPY FILE statement (which can cause the error), I check the custom property. If it's true, I set it back to false, set the return value of the method to the FILE_ERRORHANDLED (indicating I trapped it) and set the cErrorMessage (a VFE property used for the text of an error message) to a nice description and don't continue processing.

It seems ugly to me have to put code in the error method, inline error trapping code in the original method AND a custom property, but it works, and I don't have to kick them out of the app, just abort the process.



>>I am trying to figure out how to trap an error in a class (error 3, file is in use), and then raise a custom error that gives the user a better explanation. I don't want to use a messagebox or anything like that. This is a business level class, and I really like to keep interface out of it if possible.
>
>How about surpressing all errors, storeing the error number in a property (nError) and returning a .F., indicting failure.
>
>Then the calling object should be able to tell that it failed, look at the public nError property and decide what it wants to do itself.
>
>Will that work for you?