How do you handle multiple TPanel's at design-time?

Question

I have several TPanel's on my main form that I show/hide depending on options a user selects. The problem is that at design time I have to constantly move them around to edit them. Is there an easier/better way that others handle this situation?

Answer 1

If only one panel is visible at a time, then you might want to use a TPageControl to organize things. You can click the tabs to select which one to work on at design time, and then hide the tabs at run time, or hide the tabs all the time and select pages by setting the ActivePage property.

Answer 2

Use the Structure Pane to find the one you want, and then bring it to the front.

_{(source: embarcadero.com)}

(But don't follow Embarcadero's example above; give your controls meaningful names so your controls are easier to tell apart.)

Answer 3

If the panels are stacked, you can reorder them by right-clicking on one and choosing Control->Bring to Front or Control->Send to Back from the context menu.

Answer 4

A caveat I've found when doing Panel1.Visible:= false in runtime is that it messes up with layout.
The solution I've found works is to do:

//Design time
//-----------
Panel1.BevelOuter:= bvNone; //Make the panel look flat.

//Run time when hiding the panel
//------------------------------
procedure HidePanel(APanel: TPanel);
var
  H,W: integer;
begin
  case APanel.Align of 
    alTop, alBottom: begin
      APanel.Tag:= Max(APanel.Tag, APanel.Height);
      APanel.Height:= 1;
    end; {alTop, alBottom:}
    alLeft, alRight: begin
      APanel.Tag:= Max(APanel.Tag, APanel.Width);
      Panel1.Width:= 1;
    end; {alLeft, alRight:}
    alNone: begin
      H:= Max(APanel.Tag and $FFFF, APanel.Height);
      W:= Max((APanel.Tag shl 16) and $FFFF0000, APanel.Width shl 16);
      APanel.Tag:= (H or W);
      APanel.Height:= 1;
      APanel.Width:= 1;
    end; {alNone} 
    //alClient: do nothing
  end;
end;

//Run time when restoring the panel
//---------------------------------
procedure UnhidePanel(APanel: TPanel);
var
  H,W: integer;
begin
  case APanel.Align of 
    alTop, alBottom: begin
      APanel.Height:= APanel.Tag;  
      APanel.Tag:= 0;
    end; {alTop, alBottom:}
    alLeft, alRight: begin
      APanel.Width:= APanel.Tag;
      APanel.Tag:= 0;
    end; {alLeft, alRight:}
    alNone: begin
      H:= APanel.Tag and $FFFF;
      W:= APanel.Tag shr 16;
      APanel.Height:= H;
      APanel.Width:= W;
      APanel.Tag:= 0;
    end; {alNone}
    //alClient: do nothing
  end; {case}
end;

Simply hiding the panels can mess up the careful alignment you've constructed in Designtime
(esp. when using splitters).
This code prevents that from happening.
It really only works visually when the panel has no Bevels set and the panelcolor equals the color of the control it's on top of.

Answer 5

I select the Frame or Panel using the Object inspector Combo then on the main menu click Edit--> bring to front

(which is similar to opening the structure view)

Answer 6

I also have used a TPageControl, and I kept the tabs visible at designtime. This gave me a designtime usability (via clicking on the tabs I want). Then at runtime, I hide the page tabs, and switch active pages on the page control using code, as a way of switching which pane is visible. However, this lead to some horrifically huge and complicated forms, which was in turn, the cause of many problems.

For your case, I would suggest that you consider refactoring each pane into its own Form or Frame. My preference would be to use Forms, not frames, and the reasons for this are well known and well documented in the Delphi world.

In my most well-structured applications, each "pane" (implementing using TForm, though, not TFrame) is separated into different units, and this solves both your design-time control problems, and also results in a more well structured overall solution.

While I think that the Structure Pane (someone else pointed out) is a great help to you, when you want to work with forms that are so complex that the regular designer visual tools start getting harder to use, it is also a good idea to consider breaking your form up, when you reach this point of "diminishing returns" of using the form Designer, on what is becoming one super-super complicated form.

Answer 7

It is much easier to use frames for this purpose. I usually create them at runtime and add them to the form as needed. It also tends to make the code much more readable because you can use the same component names (e.g. ed_Name or l_Welcome) on different frames without having name clashes rather than having ed_NameForPanel1, ed_NameForPanel3 etc.