>You actually want the default VFP behavior - the cancel-suspend-debug-ignore-help dialog?

eggsaccly!

Then issue ON ERROR with no arguments at all, i.e. switch it completely off.

Nope. Done that. Both from the command window and in the Load method of the form...

> You probably got some default error handler from FFC classes.

yes, this is a possible as I have vpm installed. But I am not in the vpm environment when this behaviour occurs. And, it must be said, the vpm design time error handling is utterly appalling and frequently necessitates a TFS. I think I'd recognise it if this were standard vpm error handling! This is merely irritating not suicide inducing. Which is not to say it can't be anything to do with vpm, but I can't figure out how to check.

>
>? on("error")
>
>will give you the current error handler setting. You may even save it into a variable,

and throughout the 'run form' exercise, it returns a null string, showing that I've successfully switched error handling off

nevertheless, instead of crashing on the offending line (I can step through the guilty line and watch this happen), despite having defused the error handler, the code leaps to the error method for the form where I've inserted a nodefault in the attempt to stall it. It then protests 'no parameter statement found' and crashes in the normal way - i.e. at the offending line! Trouble is the offending line is now the first line of the error method and not the code line that caused the jump in the first place.

Harry