Page 1 of 1

Has a parent form been closed?

Posted: Sat Jun 25, 2011 7:08 pm
by JDev30
How do I tell if a calling / parent form has been terminated?

The situation I have right now is a "Manage objects" form which creates an instance of the Edit form, running a "setCallingForm" method which sets a reference back to the calling form, when the edit form closes it tells the Manage Objects form that it has closed by running a form. This works but if a user closes the Manage objects form before the Edit Objects form, it gives the error "Object not found" because the calling form has been unloaded.

Is there a boolean test that can tell me if the calling form is still loaded? "if getCallingForm() <> null then..." also produces the above error.

Re: Has a parent form been closed?

Posted: Sat Jun 25, 2011 7:51 pm
by torrie
There's a couple of things you could try:

1) You can use the app.isValidObject method to check if the reference to the parent form is still valid.
2) Add a collection of child forms on the Manage Objects form and inverse this to the Calling Form reference on the child forms. If the parent is unloaded, then the reference on the child forms will be set to null.

If you choose option 2, then you could implement the QueryUnload event on the Manage Objects form and check if there are still edit forms open before allowing the manage objects form to close.

Re: Has a parent form been closed?

Posted: Sat Jun 25, 2011 8:12 pm
by JDev30
Thanks torrie! Using app.isValidObject works well. I've been looking for a solution to this problem for a while and am thankful to have been shown one :)

Re: Has a parent form been closed?

Posted: Mon Jun 27, 2011 9:28 am
by BeeJay
Bear in mind that using app.isValidObject is a method that should seldom ever need to be used in real production code.

ie: If you get an error 4 and the fix being considered is to simply wrap an app.isValidObject call around the code in question, you have to have a very good reason to justify the validity of using this code construct versus other often more elegant approaches to avoid the situation that caused the error 4.

Cheers,
BeeJay.