Delphi – Should I use delphi tframes for multi-pages forms

delphitframe

I have some forms in my application which have different "states" depending on what the user is doing; for exemple when listing through his files the form displays some data about that file in a grid, but if he clicks on some button the grid is replaced by a graph relating to it. Simply said, the controls in the form depends on the what the user wants to do.

Of course the obvious way of doing that was showing/hidding controls as needed, works like a charm for small numbers but once you reach 10/15+ controls per state (or more than 3 states really) it's unusable.

I'm experimenting with TFrames right now: I create a frame for every state, I then create an instance of each frame on my form on top of each other and then I only display the one I want using Visible – while having some controls on top of it, out of any frame since they all share them.

Is this the right way to do what I want, or did I miss something along the way ? I thought I could create only one tframe instance and then chose which one to display in it but it doesn't look that way.

Thanks

Best Answer

Looks like Frames are an excellent choice for this scenario. I'd like to add that you can use a Base Frame and Visual Inheritance to create a common interface.

And to the second part: You design a Frame like a Form but you use it like a Control, very few restrictions. Note that you could just as easily use Create/Free instead of Show/Hide. What is better depends on how resource-heavy they are.

Related Solutions

Delphi – Showing TFrame descendant’s additional properties on the object inspector

Which custom module class are you registering for your frame? Which version of Delphi are you using?

From my experiments with Delphi 2007, the custom module class which seems to work is TFrameModule. This class is contained in delphivclide100.bpl. Since there is no corresponding delphivclide.dcp you have to load it manually:

unit FrameTestReg;

interface

procedure Register;

implementation

uses
  Windows, DesignIntf,
  FrameTest;

procedure Register;
var
  delphivclide: THandle;
  TFrameModule: TCustomModuleClass;
begin
  delphivclide := GetModuleHandle('delphivclide100.bpl');
  if delphivclide <> 0 then
  begin
    TFrameModule := GetProcAddress(delphivclide, '@Vclformcontainer@TFrameModule@');
    if Assigned(TFrameModule) then
      RegisterCustomModule(TTestFrame, TFrameModule);
  end;
end;

end.

My FrameTest unit is very simple, it has no FrameTest.dfm, only the declaration of the new TFrame descendant:

unit FrameTest;

interface

uses
  Forms;

type
  TTestFrame = class(TFrame)
  private
    FHello: string;
  published
    property Hello: string read FHello write FHello;
  end;

implementation

end.

Using TFrameModule class, everything seems to work fine so far. I can create a new descendant of TTestFrame to include in the project and edit its published properties in the Object Inspector, put instances of this new descendant on a form in the IDE, edit their new published properties in the Object Inspector, write event handlers for their child components etc. In the .dfm resource I can see the expected "inline" directive for the instances. I haven't encountered any problem with it so far so perhaps this is the solution.

Delphi – Registering a custom Frame

I have fairly extensively explored using TFrames (and their related inheritance) as a base for component development, and could elaborate on what I've found if it would be useful, but I have never had need of using RegisterCustomModule -- I just develop from TFrames directly, using normal frame inheritance, and then register the resulting "final" versions in a standard component registration unit. This seems to allow the best of both worlds (visual development + inheritance, plus component palette + object inspector capabilities).

There are a number of little tricks to it though, and snags to watch for, such as how you name the TFrame itself, making sure the DFM files use "object" or "inherited" properly on the first line, and, in general I have found it very beneficial for stability of complex inheritance trees to create a "base frame" that inherits from TFrame, but adds NOTHING to it... and then inherit all the others from there. (This seems particularly true when adding published properties etc).

Tell me more about why in particular you are wanting to use an IDE Wizard, and maybe if that is not cast in stone as an approach, I can be of more help.

Related Topic