>>What is the sequence in which error handling is processed? In my particular instance, I'm trying to remove from a page in a pageframe all labels of a certain name. I'm doing this in the valid of a textbox on the main form. My code is

>>WITH thisform.pframe
>>     .
>>     some code
>>     .
>>	WITH .pgPassFail
>>		** Remove the "Board Number" objects from the pass/fail page
>>		iBoard = 0
>>		DO WHILE .T.
>>			iBoard = iBoard + 1
>>			TRY
>>				.RemoveObject(".lblBoard"+TRANSFORM(iBoard))
>>			CATCH
>>				EXIT
>>			ENDTRY
>>		ENDDO
>>	ENDWITH
>>     .
>>     more code
>>     .
>>ENDWITH

>>
>
>I believe try/catch has priority over anything else. Have you verified the above by adding a messagebox in the CATCH block instead of exit? Perhaps exit doesn't work here, you need to set a variable instead and use it to test to check if you should exit.

That's what I thought also.

What happened during my testing of the code block (which has several bugs in it) was that there is a SET STEP ON just before the DO WHILE loop. When I stepped into the offending line of code in the TRY block the next line of code in the debugger was from the form error handler. It didn't even point to the EXIT line in the CATCH block.

We had the same problem in another piece of the application. We tried to do a SETFOCUS() into a different control from within the VALID of a textbox. The code was wrapped in a TRY/CATCH but the form error method took over.

As I have several different ways of rewriting the code this isn't a "gotta get it done" issue but more of a "I wonder why" kind of question. I appreciate your help but, other than increasing my fund of knowledge, it isn't worth you putting any extra effort researching it further.

Thanks............Rich