rHowe11


Arrgg!

If I had a dime for every hour I've spent wrestling with Foxpro's error handling paradigm...

Here's a new gotcha: Apparently, when an error occurs in a combo box valid event handler, and the error is handled by a try/catch block outside of the form, a reference to the combo object is stored in some mystery memory location, preventing the combo box (and thus the form) from being destroyed. The only way to destroy the form is to first remove the combo box object with the RemoveObject method. The only way to destroy the orphan combo box appears to be to issue CLEAR ALL.

Please - Tell me I'm wrong! I'd love to eat crow...

Randy

*

**- example executable code -**

LOCAL loEx, loFrm AS form

TRY

loFrm = CREATEOBJECT("frmCrash")

loFrm.Show

READ EVENTS

loFrm.Release()

CATCH TO loEx

MESSAGEBOX(loEx.Message)

**- combo1 must be removed from form or form will not be destroyed

IF VARTYPE(_Screen.ActiveForm) = "O"

IF VARTYPE(_Screen.ActiveForm.ActiveControl) = "O"

_Screen.ActiveForm.RemoveObject(_Screen.ActiveForm.ActiveControl.name)

ENDIF

ENDIF

loForm.Release()

ENDTRY

**- but alas, combo1 is still referenced somewhere.

CLEAR ALL && not a very pragmatic solution!

**- end

DEFINE CLASS frmcrash AS form

ADD OBJECT combo1 AS combobox WITH Name = "Combo1"

ADD OBJECT cmdquit AS commandbutton WITH ;

Top = 50, ;

Caption = "Quit", ;

Name = "cmdQuit"

PROCEDURE combo1.Valid

IF NOT EMPTY(This.DisplayValue)

This.DisplayValue = ""

ERROR "Combo Valid Error"

ENDIF

ENDPROC

PROCEDURE combo1.Destroy

WAIT "Combo Destroy" WINDOW TIMEOUT .25

ENDPROC

PROCEDURE cmdquit.Destroy

WAIT "Command Destroy" WINDOW TIMEOUT .25

ENDPROC

PROCEDURE cmdquit.Click

CLEAR EVENTS

ENDPROC

PROCEDURE Destroy

WAIT "Form Destroy" WINDOW TIMEOUT .25

ENDPROC

ENDDEFINE

**- end code example -**




Re: Foxpro's Dirty Little Secret?

Fernando D. Bozzo


Hi:

The problem is at the bigining:

Replace this:

loForm.Release()

with this:

loFrm.Release()







Re: Foxpro's Dirty Little Secret?

rHowe11

That's just a typo when I transferred the code to the forum.

The bug still stands.






Re: Foxpro's Dirty Little Secret?

Dan Freeman

What bug

The code works just fine for me, once I fix the typo.

I commented out the CLEAR ALL and the code still works just fine.

What version are you running Is this in the CTP

Dan


(later)

Ooops! I see it now. (Have to also comment the removeobject()) Have you reported it




Re: Foxpro's Dirty Little Secret?

rHowe11

I guess I was waiting to see if someone else could reproduce this. If you commented out the CLEAR ALL you should have noticed that the combo box was no longer destroyed. Worse yet, if you run the program again, the problem compounds.

I need a work around or I'm in serious trouble! If I had some way to release the errant object without using CLEAR ALL, I'd be OK (but still crabby).

How do I report it

Randy





Re: Foxpro's Dirty Little Secret?

Fernando D. Bozzo

I've dropped the timeout of combo1.valid's wait window and I can see it now, but with a timeout of 0.25 can't be seen!

I see two possibilities now:

1) You can put the valid's code in a try/catch and ejecute some method of the main program (Don't Throw!)

2) You can fire a main timer (out of the form, in the main program) with a reference of the form with an interval of 100 or less and let the timer release the form

Regards.






Re: Foxpro's Dirty Little Secret?

jTorkyt

I ran your code sample an comment out the part that remove the combo and it is release as I close the form via the command button. I see the three messages and the form goes out.


By the way I'm using VFP 9 With Service Pack 1, maybe You not; if that is your case get it and try with it to see if is the version that You are using.

Notice that You not use loEx in the code.





Re: Foxpro's Dirty Little Secret?

CetinBasoz

jTorkyt,

Probably you didn't enter any value to combo causing it to error. When it errors you can see the bug.





Re: Foxpro's Dirty Little Secret?

rHowe11

Thanks for your input.

Perhaps I should have been more descriptive with my code example.

With the exception of the typo noted above, the code as listed will run.  However, if you trigger an error by typing an entry into the combo box, the program runs only because: 1) the combo box is removed from the form before the form is released, and 2) the CLEAR ALL removes the combo box from memory.  If you comment out CLEAR ALL, the combo box is not destroyed.  This can be proven by subsequently executing CLEAR ALL in the command window.  If you comment out the code that removes the combo box object from the form, the form cannot be destroyed and just stubbornly sits there - LOOK FAMILIAR

By the way, this same problem also occurs with the When event handler, and I've seen similarly errant behavior relating to textbox and editbox controls as well.  When you think about it, When and Valid are both events that utilize return values that allow/reject object navigation.  Hmm...

I believe the key to this errant behaviour is the "mystery" reference that is created (or abandoned) when the error occurs.  By remaining in memory, the reference prevents the combo and thus the form from being destroyed.

This problem belies much of the usefulness of Foxpro's Try/Catch functionality, and probably speaks to the design of Visual Foxpro itself. 

I suppose I could just plan on writing error free code...

Randy - loyal since v1.0