How does OnFormClosed() call into a control's OnLoad()?

Posted by Simon L. Prinsloo on 15-Nov-2018 07:30

Good Morning

I am in the process of tracing a error.

It that used to crash the UI with an error that the .Net was calling into an already deleted object when the form is closed. From another thread on the forum I know that Progress changed the sequence of stuff during disposal/finalisation, in 11.7.4 and installed that in the hopes that it would solve the problem.

Now, when I close the Form I get an error message about something that goes wrong in our code (an initialization that happens a second time) with a very weird stack trace, looking like this:

OnLoad ...KoineViewerControl at line 48 (C:\Projects\....\KoineViewerControl.r)
OnFormClosed ...BaseForm at line 1849 (C:\Projects\...\BaseForm.r)
Menu\start.p at line 660 (C:\Projects\...\start.r)

Line 660 of start.r is the WAIT-FOR statement of the startup procedure.
Line 1849 of BaseForm.r is "SUPER:OnFormClosed (INPUT e)."

BaseForm inherits directrly from Progress.Windows.Form.

Thus it appears that when BaseForm's OnFormClosed calles into Progress.Windows.Form OnFormClosed(), something goes wrong and we end up in the OnLoad() of the viewer (ultimately a Progress.Windows.UserControl) on the form.

Can anybody explain this or does anybody have an idea how to get around this?

Regards
Simon

All Replies

Posted by Mike Fechner on 15-Nov-2018 07:38

Can you share the .NET stack trace?

I have seen similar things. If I recall, some .NET code required to call Control.Load again to re-initialize a .NET control that was already unloaded... Need more coffee for  more details.

Solution was to use a flag to ensure your OnLoad code only executes once.

The .NET stack trace might shed some light.

Sent from Nine

Von: "Simon L. Prinsloo" <bounce-simonvidisolvecom@community.progress.com>
Gesendet: Donnerstag, 15. November 2018 08:31
An: TU.OE.Development@community.progress.com
Betreff: [Technical Users - OE Development] How does OnFormClosed() call into a control's OnLoad()?

Update from Progress Community
Simon L. Prinsloo

Good Morning

I am in the process of tracing a error.

It that used to crash the UI with an error that the .Net was calling into an already deleted object when the form is closed. From another thread on the forum I know that Progress changed the sequence of stuff during disposal/finalisation, in 11.7.4 and installed that in the hopes that it would solve the problem.

Now, when I close the Form I get an error message about something that goes wrong in our code (an initialization that happens a second time) with a very weird stack trace, looking like this:

OnLoad ...KoineViewerControl at line 48 (C:\Projects\....\KoineViewerControl.r)
OnFormClosed ...BaseForm at line 1849 (C:\Projects\...\BaseForm.r)
Menu\start.p at line 660 (C:\Projects\...\start.r)

Line 660 of start.r is the WAIT-FOR statement of the startup procedure.
Line 1849 of BaseForm.r is "SUPER:OnFormClosed (INPUT e)."

BaseForm inherits directrly from Progress.Windows.Form.

Thus it appears that when BaseForm's OnFormClosed calles into Progress.Windows.Form OnFormClosed(), something goes wrong and we end up in the OnLoad() of the viewer (ultimately a Progress.Windows.UserControl) on the form.

Can anybody explain this or does anybody have an idea how to get around this?

Regards
Simon

View online

 

You received this notification because you subscribed to the forum.  To stop receiving updates from only this thread, go here.

Flag this post as spam/abuse.

Posted by Simon L. Prinsloo on 15-Nov-2018 07:59

How would I find the .Net stack trace? I obtain the current stack trace by clicking the Help Button on the Message Box.

Posted by Mike Fechner on 15-Nov-2018 08:08

System.Environment.CallStack() .

Posted by Laura Stern on 15-Nov-2018 14:23

Clicking the Help Button on the Message Box will also give you the .NET part of the stack if .NET routines were on the stack when the error happened.  I assume OnFormClosed is an override of the base-class method.  Therefore, it seems odd that there is no .NET stack there.

This thread is closed