Re: Newbie question about release, freeAndNil, etc

"swansnow" <schultz@xxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:1124997970.629880.274680@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
[...]
> When you create a Form, Delphi gives you a global variable to use. We
> actually use them, so in our code we have things like:
>
> i.e., in a button click handler:
> if not assigned(frmViewerOptions) then
> frmViewerOptions := TFrmViewerOptions.create(application);
> frmViewerOptions.showModal;
>
> etc
>
> What is the recommended way of freeing these forms? ...

First off, I do not mean to contradict anything Rob said.

There are basically two scenarios. Modal forms are popped up
synchronously and generally not reused. That makes them very
convenient to program. A single function can create it, show
it, and free it, using only its own variables or any unused
global variable.

Nonmodal forms, for example floating property windows, can be
less straightforward. If you always want to have only one
instance in existence, the global form variable can be a good
place to keep track of that existence. The form can free itself
on closing and then the variable should be cleared; or it can
simply be hidden. The form can also be either autocreate or
create-on-use. It all remains straightforward. The calling code
_can_ be the same for any of the combinations, with a bit of
work and allowing for a tiny bit of inefficiency (never my
greatest concern).

If several instances may coexist, you can no longer use the
global form variable and you probably need to keep a list
somewhere of existing instances and what data they display.
The forms should preferably register and unregister themselves
with this list from the constructor and destructor, and be
free-on-close so you don't go nuts juggling them. Basically,
the single variable is replaced by a collection.

There are several ways to get a form to free itself on closing.
The RAD as well as the idiomatic way is to set Action to caFree
in an OnClose handler. An alternative to setting Action is to
call Release; an alternative to writing an event handler is to
override the event dispatcher.

Instead of freeing the form on closing, you might also close the
form by freeing it. The File-Exit menu handler can call Release
instead of Close. But you probably don't want to do this; it
doesn't play well with the window's close button.

I acknowledge Rob's uneasiness about separating the responsibility
for creating and destroying the form; however it's part of the
pattern of "fire and forget" that the form should be defined to
clean up after itself. The responsibility is not shifted just
anywhere but to the (visual) object _itself_. This is, IMO, a
crucial difference and warrants creating an object and leaving it
orphaned. It's not an orphan really; it should be considered an
autonomous adult.

Your variation #1 is my accepted pattern for modal forms. #2 uses
Release without cause; Release was introduced to get around an
obscure dependency and should not be used unless necessary. Use
Free instead. #3 is a double free. #4 is how I'd do a nonmodal
singleton, although I can't remember the last time I did. #5 is
the same as #4 except it uses Release correctly yet still wrong.
Use Action instead.

Groetjes,
Maarten Wiltink


.

Quantcast