tags:

views:

401

answers:

4

I was having my usual stroll around SO 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 witch is:

  • Create a TFrame inside it's 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?

+8  A: 

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!
Steve
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.
Svein Bringsli
@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.
Gustavo Carreno
+4  A: 

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.

Jeroen Pluimers
+1  A: 

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.

Marco van de Voort
Yeaps, makes sense. If you have too many frames something is definitely gonna break.
Gustavo Carreno
It's more that there is a risk that windows messages for a frame will arrive even though the frame has been reparented.
Marco van de Voort
+3  A: 

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
dummzeuch
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!!
Gustavo Carreno