>Is here any expert which can be explain this strange behavior?
>
>Example package: http://gorila.netlab.cz/download/bugs/SB_VFP9.0-doform.zip
>
>Parts:
> tryendtry.prg - DO FORM and TRY...ENTRY
> onerror.prg - DO FORM and ON ERROR
>
>Description: Procedure RunModule() is main procedure in microkernel for running any form, report, program or procedure. Procedure APPMAIN() is proxy proram in each apllication.
>
>After run the form is steel exist and cannot be terminate, with excpetion CLEAR ALL.
>
>If you move object Label1 from page to form, the form after error handling is terminate correctly.

You can call it a bug,
because the CATCH stop the form construction stops halfway
leaving some structures of VFP incomplete;
BUT it is very hard for VFPT to control every possible error.

The native error trap design ( ON ERROR and Error() ) was designed correctly,
TRY..ENDTRY allows greater control inside a procedure,
but put into an OOP it is much more critical.


Even if you can get a reference to the form,
you can not release it!

CLEAR
PUBLIC myForm,loadForm
PRIVATE pcPath
pcPath=JUSTPATH(SYS(16))

DO RunModule

PROCEDURE RunModule
?"form count before run:",_screen.formcount,_VFP.Objects.count
TRY 
  DO APPMAIN

CATCH TO loXX
  ?"error at running form..."
  ?CHR(9),"erorrno:",loXX.ErrorNo
  ?CHR(9),"message:",loXX.Message
  ?CHR(9),"procedure:",loXX.Procedure
ENDTRY
?"form count after run:",_screen.formcount,_VFP.Objects.count
? "m.myform doesn't change",m.myForm 
? "m.loadform exists",loadform.name
* but it is a zombie!
loadform.Release
?"form count after release:",_screen.formcount,_VFP.Objects.count
RETURN

PROCEDURE APPMAIN
  DO FORM (pcPath+"\tryendtry") NAME myForm && NAME it is not applied because the C++ routine is stopped

* on tryendtry.scx Load
STORE m.this TO loadForm

Since CATCH stop the construction of the object,
procedures for release in VFP not work.
only a CLEAR ALL release all.

In other words, you must allow VFP to conclude construction,
and this can only be done by checking Error with Error()
If you put a * comment in label.Error event,.
then you can take control of the situation.

In my opinion it is very difficult to control a VFP program without using VFP Error() events.