Delphi: Is it ok for a form to free it self?

Question

I have a form that I use to show some information for some seconds. Is it ok for the form to free itself? Can I start a timer in the constructor, and then call self.free in the timer-event? Or will this potentially lead to trouble?

Birdwatcher

According to the manual, inside of event handlers, you MUST call Release instead of Close or Free. docwiki.embarcadero.com/Libraries/Sydney/en/… – Krute

Answer 1

In addition, with a form you can call Release.

It sends a CM_RELEASE message to the form. As a reaction it calls Free. The advantage of release is that there are no messages left for the form which could result in a crash.

Shallow

I think I will go for this one, in combination with setting the owner as a extra insurance. – Birdwatcher

@Rigel, not exactly, Close uses CloseQuery which can be used to interrupt the process and it is not guaranteed to free the form. Depending on the cloise action, the form can also hide or minimize (Have a look at TCustomForm.Close in Vcl.Forms.pas. – Shallow

Yes. Of course. Close will or will not close the form, depending on how you set the close action. But I was speaking about something else: (if it set to caFree) .Close is as safe as .Release. I mean it will not create the problems that .Free will create. – Krute

Answer 2

You can make the form to free itself when it gets closed by the user or from code:

procedure TForm27.FormClose(Sender: TObject; var Action: TCloseAction);
begin
  Action := caFree;
end;

procedure TForm27.FormCreate(Sender: TObject);
begin
  Timer1.Enabled := True;
end;

procedure TForm27.Timer1Timer(Sender: TObject);
begin
  Timer1.Enabled := False;
  Close;
end;

Make sure you supply an owner in the constructor incase the application shutdowns and the form is not destroyed at the time. The owner will free the form before freeing itself.

Guessrope

The more I think about it, the more I like the TCloseAction-idea. Maybe I should use that instead of release... – Birdwatcher

if only forms had DefaultCloseAction properties, so pone could auto-free them without assigning event handlers. – Saville

Answer 3

I have a whole suite of objects that free themselves, and I've run various tests on them with no problems/leaks shown. A TForm might be more complex, but as long as Self.Free() is the last call made, you ought to be safe.

(For those wondering why on earth I have object that free themselves; I pass them around the system a lot, so I implemented by own reference counting scheme. When the last reference is released, so the object frees itself).

Tonietonight

But Self.Free would almost never be the last call made by a form because a form is almost always running code in reaction to some user action. Use Release instead. – Dah

Why not just use Interfaces for reference-counting? – Psychological

Answer 4

This is exactly what is done with Interfaces.

Benignant

Yes, but you should remember that Delphi's TComponent overrides the interface's reference counting, which often causes confusion. – Tallula

Using interfaces, the form would be freed when it goes out of scoop. I don't want that. I want it to live as long as it wants without any references to it, and then free it self when its done showing it self. – Birdwatcher

Fabio: I'm sure you could override that. Vegar: Interfaces are reference counted, not scope-managed. – Benignant

Yes, but as long as you don't keep a reference, wouldn't the referencecount go to zero when the code where you created the form goes out of scope? – Birdwatcher

Only if you never pass it to something else... When you create the object, the ref gets incremented, so it is 1. When you assign it to something else, it becomes incremented again, so it is 2. When it leaves scope, it gets decremented, to ONE, and thus isn't destroyed. – Benignant