What is the accepted way to use frames in Delphi?

Question

I was having my usual stroll around and bumped on some frames discussions.

I'm mainly a Delphi hobbyist and not a professional, so I had to learn how to use TFrames my own way which is:

• Create a TFrame inside its unit.
• Add that unit to the main form Uses clause.
• Have a private variable of that TFrame's type
• OnCreate of the form instanciates the TFrame and attaches it to a TPanel both on the Create and .Parent
• On one of my Actions set that TFrame.Visible := True and .BringToFront.

This is my practice after some personal deliberation.

What other ways can one use the frames?

Esteresterase

You might also be interested in this: thoughtco.com/… – Darkling

ThoughtCo article gone. – Boffa

Here is the archived version of the article: web.archive.org/web/20201125173042/https://www.thoughtco.com/… – Fructose

Answer 1

That's one way, and there is nothing wrong with it. Another way, is to to do it visually. So you can basically add the frame to a form. to do this you :

• Create your Frame.
• Go to the form you wish to put your frame on.
• Add a Frames component (Standard Tab)
• Choose your frame from the drop down.
• That's it!

Gloaming

This is my preferred method also, but in certain circumstances I find it useful to create frames "on demand". Especially for frames that are used as part of a tabbed control and might never be shown. – Darreldarrell

@sveinbringsli: yeah that would be my thought too. Too much memory waste to create' em all if your user will only use one or two. – Esteresterase

Sometimes it does not work. When you want to put the Frames component on your form it says 'There is no frames in the project...'. That can be solved by manually adding the frame into your project - in Project Manager right click on your project and then Add. – Scifi

Answer 2

The only problem with your approach is that you cannot add multiple instances of the same frame to a given form:

Frame1 := TMyFrame.Create(Self);
Frame1.Parent := Self;
// ...
Frame2 := TMyFrame.Create(Self); // bombs out with "a component with the name MyFrame already exists"

The workaround for his is to assign a different name for each instance:

Frame1 := TMyFrame.Create(Self)
Frame1.Parent := Self;
Frame1.Name := "FirstFrame";
// ...
Frame2 := TMyFrame.Create(Self); // works now, there is no name conflict

Edit: It's also possible to assign an empty string for the name, so you don't need to come up with a unique name for each instance.

Fructose

Thanks for the idea. I usually only need one frame per functionality but it would happen soon enough that I would need multiple instances. Thank you!! – Esteresterase

Answer 3

You can even go a step further, by registering your frames as components.

That disallows you to edit properties of components on the Frame as soon as the Frame component is on the form. But I think that is a good thing.

You need to one more thing than registering your frame as a component, as I explain in this article about Delphi – Frames as visual Components – don’t forget your Sprig!.

That knowledge is not mine: I got it from Ray Konopka during one of his sessions at the Delphi Live conference in San Jose earlier this year.

Bolt

Answer 4

This is more a negative answer, but I tried a route that included reparenting TFrames for a bit complex GUI.

At first it went fine, but when the application matured and more events started flying, I had to disable and then process messages for a while (20ms) before changing, and then still occasionally had crashes when changing frame.

One of the culprits I eventually found, TPopmenu also registers itself in global datastructures. This reduced the problems, but they were still there, so I move away from the concept.

Nagpur

Yeaps, makes sense. If you have too many frames something is definitely gonna break. – Esteresterase

It's more that there is a risk that windows messages for a frame will arrive even though the frame has been reparented. – Nagpur