Question

Working with my ongoing TFrames-based component set project, I’m coming across various instances where I am wanting to replace one of the TFrame’s components (usually non-visual) at runtime with one that is generated dynamically at runtime.

I think I’ve probably found the answer to my immediate problem here, but in my own digging around and experimenting prior to finding that, it’s become clear I’ve got quite a bit to learn about how Delphi handles object references, particularly with respect to forms/frames, and (in general) class properties which are object references rather than non-pointer values.

A specific example of one experiment is here:

(On a form with three TButtons)

procedure TForm1.Button3Click(Sender: TObject);
var
  MyButton : TButton;

begin
  MyButton := TButton.Create(Self);
  MyButton.Caption := 'New Button';
  MyButton.Parent := Form1;
  Form1.Button2 := MyButton;
  Form1.Repaint;
  ShowMessage('Button2 caption = ' + Form1.Button2.Caption);
end;

Doesn’t replace Button2 with the created button, but does show both on the form. The ShowMessage results indicates Button2’s caption still = “Button2”

I find myself asking questions like, “Is this ‘non-replacement’ unique to forms, or would that be true for other classes as well?” etc. In short, I’ve discovered yet another sinkhole of my own ignorance. 😉 I find in working with instances/object references/derefencing/class definitions/class properties etc, that oftentimes things behave exactly as they expect them to, but other times, not at all, and not even close.

It’s clear I need to study up on this area. Rather than post stupid question after stupid question revolving around this subject, I thought I’d ask this instead:

What is a really good reference or tutorial for getting a better grasp on the subtle distinctions re: how Delphi handles such things?

Thanks in advance for all your help!

Answer 1

Those fields on the forms are there purely for your convenience when writing code. You can delete them from the .pas file and they’d still show up. The form’s layout is defined in the DFM, and the form object holds an internal list of references to the controls placed on it, just like any other visual control.

I don’t know about tutorials on the subject, but I do know how you can replace a button. You’ve got it mostly right, but you also have to free Form1.Button2 before you overwrite the reference. That will cause the button to remove itself from the form’s control list as part of its destruction process. Or, if you want to save the button somewhere instead of destroying it, call Form1.RemoveControl(Button2); instead.