Executing method Release in form when Reference COUNT IS 0 of Form

[mstrcmtr]

On issuing the following command in a Form Command button Name [CmdExit] Click Event

thisform.Release()

How can assure that reference count is 0 of Form Object before releasing Form through release method

 

[Mike Lewis]

You might find this article useful:

http://doughennig.com/papers/Pub/Oct99.pdf

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

The article mentions ObjRef and AINSTANCES() and the inability of the latter to know inaccessible object references. This alone makes it quite impossible to tackle the problem without any problems.
If your goal is to reliably release a form, you accept those properties referencing the form to become references to a non existing form, so acting this way and simply tuning the object ref count VFP manage to your need to release the form is risky. Any later access to a form ref then errors.

On the subject there also are some links worthwhile reading from Christof Wollenhaupt:

http://www.foxpert.com/foxpro/knowlbits/files/knowlbits_200908_3.HTM

http://www.foxpert.com/docs/safeclasses.en.htm

I'd tackle this by having a good form handler implementation. Don't store form references anywhere else but in Collections, because they have a feature making such references keeping a form up a thing of the past. Because releasing a form automatically removes references from collections. How does that help, if references are also stored elsewhere? Well, that's the core thing to avoid.

1. Every form started should only be started by a form handler
2. The form handler stores a reference to its forms collection
3. Anyone (any further code or object) needing a certain form reference asks the form handler for it, instead of storing it itself in some property. For this to work, you need a good concept of keys identifying forms, the collection again makes it easy to lookup a reference by key, as a collection is based on the core concept of managing its items via keys as lookup reference. Keys here are any string value - the class name of a form, for example, whenever you only want one form instance, or any other concept fitting, like class name + instance number.
4. You only keep form references you get from some form handler method in local variables and thus avoid any further reference to permanently increment the form ref count.

Finally, this will then mean there only will be the one reference stored in the form handler collection and that is automatically removed, even if just doing form.release and not delegating the release as a task of the form handler. Thus the form handler can even be passive in that respect.

It's easier to retrofit into an existing application because you only need to care for the forms registering with the form handler at init, that's less complicated than basing all classes on Christofs safe base class. And it's less of a hack than manually reducing the object ref counter via the ObjRef FLL. Indee Chrostof also has this in his Downloads section:

http://www.foxpert.com/downloads.html

(OBJREF.FLL.zip)

If you only have the problem to clean your IDE after a debug session, there is CLEAR ALL for that. Besides restarting VFP9.EXE, of course. If you experiece a long startup time, then most probably because you haven't turned off the task pane and it loks for info from the non existing gotdotnet dot com domain. See thread184-1753811

Bye, Olaf.