1. The sample code just had the line USE nodatabase as an erroneous line intentionally, just to test the error handling. Using a file, that is no database/table or doesn't even exist will of course trigger either file not found or file... is not a table error. That's not what you need in your code, that's just to test the error handling, to trigger or force an error and let happen, what was defined by ON ERROR. For example to test it and see, whether itself runs error free.
2. You do the ON ERROR command before everything. In itself it does nothing, it simply tells VFP to handle any error with the command given when it happens ON ERROR spoken in detail means "ON" the condition an "ERROR" event happens, do this or that...(whatever command you write after ON ERROR). It does not happen righgt away and it's not a command you put somewhere to do something on the condition an error happened in the previous line, it always and only does what you define from that moment onwards.
So no, you don't put ON ERROR after the PUTFILE call, you put it as soon as possible before executing any further code. The typical start code involves some SETs and an ON ERROR definition. If you have your errorhandling routine as a separate PRG you first should have some SET PATH and SET PROCEDURE settings, if you call a procedure within your main.prg code or you specify the full path to the PRG in a [tt]DO D:\path\to\ERRCATCH.PRG WITH parameterss[/tt] (pseudocode, don't take it literally), the ON ERROR could also be the first line of your code, so anything following, when causing any error, will trigger the error handling routine. Of course it's also one major condition, that the command you set up for error handling finds the PRG or function you let it execute.
Your original error handler seems to have PROGRAM within its own code, so it displays its own name ERRCATH in a messagebox, that's obviously not how this should be done, because you don
t really see where the error occurs, you can only guess from the last thing the user (or yourself) saw happening. The error could be next line, it could be far down the drain already, much code can happen in split seconds. Since it has to do with some OLE control the expected context is that control, maybe something you do with excel automation with the given filename.
In the context of ON ERROR being triggered PROGRAM() will have the value of the progrm having the error, within the error handling routine PROGRAM() will be the name of the errhandler prg, that's why it's important you have PROGRAM() as parameter, not within the handling code.
You should use code references tool, to find out where in your project the error handler is and where it is established as handler, where you have an ON ERROR line, instead of defining your new error handler now, and then extend it's parameterization and it's inner working. Mike assumes this isn't an error handling routine showing that messagebox in your screenshot, I assume it is a VFP messagebox, not the native one you get with no error handler routine established, but something, that's poorly constructed. It's important you find this, because whatever you set up as new error handling most probably isn't in effect later, as the poorly written error handling routine takes over the moment anywhere in your project ON ERROR redirects handling of errors to the already existing error routine.
Bye, Olaf.
