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
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.
There's a better way to handle dealing with the frames that won't take up nearly as much memory. Dynamically creating the frames can be a very elegant solution. Here's how I've done it in the past.
On the form, add a property and a setter that handles the placement of it on the form:
TMyForm = class(TForm)
private
FCurrentFrame : TFrame;
procedure SetCurrentFrame(Value : TFrame);
public
property CurrentFrame : TFrame read FCurrentFrame write SetCurrentFrame;
end;
procedure TMyForm.SetCurrentFrame(Value : TFrame)
begin
if Value <> FCurrentFrame then
begin
if assigned(FCurrentFrame) then
FreeAndNil(FCurrentFrame);
FCurrentFrame := Value;
if assigned(FCurrentFrame) then
begin
FCurrentFrame.Parent := Self; // Or, say a TPanel or other container!
FCurrentFrame.Align := alClient;
end;
end;
end;
Then, to use it, you simply set the property to a created instance of the frame, for example in the OnCreate event:
MyFrame1.CurrentFrame := TSomeFrame.Create(nil);
If you want to get rid of the frame, simply assign nil to the CurrentFrame property:
MYFrame1.CurrentFrame := nil;
It works extremely well.
I have a word for you : TFrameStack. Simply what the name suggests.
It has a few methods: PushFrame(AFrame), PopFrame, PopToTop(AFrame), PopToTop(Index),
and a few Properties: StackTop; Frames[Index: Integer]; Count;
Should be self explanatory.
The Frame at StackTop is the visible one. When doing ops like Back/Previous you don't need to know what frame was before the current one :)
When creating the Frame you can create and push it in one go FrameStack.Push(TAFrame.Create) etc, which creates it calls the BeforeShow proc and makes it visible, returning its index in the stack :)
But it does rely heavily on Inheriting your frames from a common ancestor. These frames all (in my Case) have procedures: BeforeShow; BeforeFree; BeforeHide; BeforeVisible.
These are called by the FrameStack Object during push, pop and top;
From your main form you just need to access FrameStack.Stacktop.whatever. I made my Stack a global :) so it's really easy to access from additional dialogs/windows etc.
Also don't forget to create a Free method override to free all the frames ( if the owner is nil) in the stack when the app is shut down - another advantage you don't need to track them explicitly:)
It took only a small amount of work to create the TFrameStack List object. And in my app work like a dream.
Timbo
I also use the approach described by #Tim Sullivan with some addition. In every frame I define the procedure for the frame initialization - setting default properties of its components.
TAnyFrame = class(TFrame)
public
function initFrame() : boolean; // returns FALSE if somesthing goes wrong
...
end;
And after the frame was created I call this procedure.
aFrame := TAnyFrame.Create(nil);
if not aFrame.initFrame() then
FreeAndNil(aFrame)
else
... // Associate frame with form and do somthing usefull
Also when you change visible frame it is not necessary to destroy previous one because it can contains useful data. Imagine that you input some data in a first frame/page, then go to the next, and then decide to change data on the first page again. If you destroy previous frame you lost the data it contains and need to restore them. The solution is to keep all created frames and creates new frame only when it is necessary.
page_A : TFrameA;
page_B : TFrameB;
page_C : TFrameC;
current_page : TFrame;
// User click button and select a frame/page A
if not assigned(page_A) then begin
// create and initialize frame
page_A := TFrameA.Create(nil);
if not page_A.initFrame() then begin
FreeAndNil(page_A);
// show error message
...
exit;
end;
// associate frame with form
...
end;
// hide previous frame
if assigned(current_page) then
current_page.hide();
// show new page on the form
current_page := page_A;
current_page.Show();
Related
This is just for learning sake : Using accepted answer in this example Delphi application with login / logout - how to implement?,how can you show a specific form (if you have many forms) ?
I have placed a query on that LoginForm (which displays various forms that can be selected and shown).
How should I change the existing code so I can accomplish this maintaining the same functionality meaning that whatever form I select and click 'open' it will become the mainform and be shown?
The main form is the first form created using Application.CreateForm. So use an if or case statement to conditionally switch which form is created that way.
In pseudo-code:
if Form1 is main form then
Application.CreateForm(TForm1, Form1)
else if Form2 is main form then
Application.CreateForm(TForm2, Form2)
....
There are quite likely slicker ways to do this, but this is the basic principle.
So, you might well make a function to return the class of the main form, using whatever mechanism you have to choose it:
function GetMainFormClass: TFormClass;
begin
Result :=...; // your logic here
end;
Then in the .dpr file you write
Application.CreateForm(GetMainFormClass, MainForm);
You seem, to be really struggling with this. I'll try to spell it out in a little more detail. The implementation of GetMainFormClass might look like this:
function GetMainFormClass: TFormClass;
var
FormClassName: string;
begin
FormClassName := ...; // somehow get the name of the form class, e.g. 'TForm1'
if FormClassName = 'TForm1' then
Result := TForm1
else if FormClassName = 'TForm2' then
Result := TForm2
else
raise EUnrecognisedFormClassName.Create(...);
end;
Personally, I don't understand why you are presenting a grid control to the user. To me that seems like a very weak user interface with which to make a selection. I would present a radio group. Then you could write code like this:
type
TMainFormType = (mftForm1, mftForm2, mftForm3);
const
MainFormClass = array [TMainFormType] of TFormClass = (
TForm1,
TForm2,
TForm3
);
Then you can have a function that returns TMainFormType, by way of showing the user a form and presenting a radio group with three buttons. You can convert the radio group's ItemIndex into the appropriate TMainFormType value.
function GetMainFormType: TMainFormType;
begin
// ... your UI shows now, presenting the radio group
Result := TMainFormType(RadioGroup.ItemIndex);
end;
And then in the .dpr file you write
Application.CreateForm(MainFormClass[GetMainFormType], MainForm);
There are lots of different ways to do this, but you do need to understand the basics of branching code. Either if statements, or lookup tables. If you don't understand how these work then, with all due respect, you need to brush up those skills before you proceed.
Originally the question had to be how to access the components in the first place, however I somehow managed to figure it out. I am just learning Delphi so I am prone to dumb and obvious questions. I am also at a stage when I'm not actually writing anything useful, but just messing with random stuff to see how it works and maybe learn something.
Wall of text incoming, i want to explain what i am exploring at the moment...
Basically i have a form1 with a button1, pressing it creates a frame2, that frame2 has a button2, pressing button2 creates a frame3 within frame2 (it being frame3's parent and owner). Each frame has an another freeandnil-button. Upon pressing each button1/2/3, it gets disabled to prevent creating multiple instances. My original problem was that after using freeandnil-button, I couldnt access the button on the previous frame (it worked fine for forms, form1.button1.enabled:=true works fine from within frame2) that got disabled in order to re-enable it (frame2.button1.enabled:=true from within frame3 creates an access violation, I think).
Suppose I write something in the future that requires such communication? So I added an editbox to each frame, with a button on the other to change the editbox text, this is my current working solution:
procedure TFrame2.Button3Click(Sender: TObject);
var i,z:integer;
begin
for i := 0 to ComponentCount - 1 do
if components[i] is tframe3 then
for z := 0 to (components[i] as tframe3).ComponentCount - 1 do
if (components[i] as tframe3).Components[z] is TEdit then
((components[i] as tframe3).Components[z] as TEdit).Text:='ping';
end;
and
procedure TFrame3.Button3Click(Sender: TObject);
var i:integer;
begin
for i := 0 to parent.ComponentCount-1 do
if parent.components[i] is TEdit then
(parent.Components[i] as TEdit).Text:='pong';
end;
If I have a bunch of editboxes or whatever the hell, I suppose I could use Tag property to identify them, however, this much component counting and passing something AS something doesn't really look right or efficient enough to me.
My questions at the moment are: can it be done in a better way? and can someone provide the reasoning why cant I access "parent-frame" components from a "child-frame" in a dumb way (ie: frame2.button1.enabled:=true from within frame3)?
A couple of points:
Controls/Components are usually set to be owned by the form/frame that controls their lifetime and parented to the control that shows them. So when you create a TEdit to sit on a TPanel on a TForm, you would set TForm as the owner and TPanel as the parent of the TEdit. With frames you do the same: the frame is the owner of all controls on it, controls are parented to whatever container on the frame (can be the frame itself) is holding and and is thus reponsible for showing (painting) it.
When you iterate over the children of a control, iterating over Components uses the Owner relation; iterating over Controls uses the Parent relation. So your code above would already do a lot less if it were to iterate over the Controls.
Of course you can reference other controls in a "dumb" way, but you will have to provide for the access method. If you want others (not just child frames) you will at the very least have to declare a method to retrieve that control. Many ways to do this. One is to "ask" the form when you need it (using a method on the form), or have the form set a property on the frame when it is created...
Avoid accessing form's and frame's published properties. They are mainly there for Delphi's streaming system. When you tie your application together using your approach described above it can very soon become one incredibly tangled mess...
Example coming up (sometime this evening), it will take me a bit of time to also explain and I have work to do...
The following example deals only with the ping-pong game between the frames. Freeing any form or frame from one of its own event handlers is not such a good idea. Use the Release method for that as it prevents the form/frame from processing messages after is was freed. (Plenty of questions about this on SO by the way). Also, when you do release a frame from one of its own buttons, you will need to take care that the frame that created it has a chance to nil the references it may have held to that frame otherwise you are setting yourself up for some interesting to debug mayhem. Look into "Notification" and "NotifyControls" and the automatic notification by forms and frames that is sent to their owner/parent so these can remove the control from their components/controls collection. In your example, if you were to release Frame3 from its own "FreeAndNil" button's OnClick event handler, you would have to make sure that the Frame2 responds to the deletion (I think) notification message and nil's any references it holds to Frame3 (besides the ones that will already be cleared automatically in the components/controls collections).
Now, the ping pong game. There are a couple of ways to go about this.
Method 1
The first way is what you already tried with a loop over the components of the other frame. While it certainly is a way to avoid having to "use" the other frame, it is cumbersome and not very concise. Plus when you get more controls on your forms/frames, you will have to add a check on the name to know that you have the correct TEdit. And then you might just as well use the name directly, especially as one frame already has the other frame in its uses clause because it is creating it.
// PingFrame (your Frame2)
uses
...
Pong_fr;
type
TPingFrame = class(TFrame)
...
procedure CreateChildBtnClick(Sender: TObject);
procedure PingPongBtnClick(Sender: TObject);
private
FPong: TPongFrame; // This is the "extra" reference you need to nil when
// freeing the TPongFrame from one of its own event handlers.
...
end;
procedure TPingFrame.CreateChildBtnClick(Sender: TObject);
begin
CreateChildBtn.Enabled := False;
FPong := TPongFrame.Create(Self);
FPong.Parent := ContainerPnl;
FPong.Align := alClient;
end;
procedure TPingFrame.PingPongBtnClick(Sender: TObject);
begin
if Assigned(FPong) then
FPong.Edit1.Text := 'Ping';
end;
And on the other end:
// PongFrame (your Frame3)
type
TPongFrame = class(TFrame)
...
procedure PingPongBtnClick(Sender: TObject);
end;
implementation
uses
Ping_fr;
procedure TPongFrame.PingPong1BtnClick(Sender: TObject);
begin
(Owner as TPingFrame).Edit1.Text := 'Pong called';
end;
This method seems all nice and dandy, but it has drawbacks:
You need to use the unit that holds the TPingFrame (Ping_fr in this example). Not too bad I guess, but... as Ping_fr already uses Pong_fr (the unit holding TPongFrame), you can't have Ping_fr using Pong_fr in the interface section and have Pong_fr using Ping_fr in the interface section as well. Doing so would have Delphi throwing an error because of a circular references. This can be solved by moving one of the uses to the implementation section (as done in the example for the use of Ping_fr in the Pong_fr unit.
A bigger drawback is that there is now a very tight coupling between the two frames. You cannot change the TEdit in either one to another type of control (unless that happens to have a Text property as well) without having to change the code in the other unit as well. Such tight coupling is a cause of major headaches and it is good practice to try and avoid it.
Method 2
One way to decrease the coupling between the frames and allow each frame to change it controls as it sees fit is not to use the controls of another form/frame directly. To do so you declare a method on each frame that the other can call. Each method updates its own controls. And from the OnClick event handlers you no longer access the other frame's controls directly, but you call that method
type
TPingFrame = class(TFrame)
...
public
procedure Ping;
end;
implementation
procedure TPingFrame.PingPongBtnClick(Sender: TObject);
begin
if Assigned(FPong) then
FPong.Ping;
end;
procedure TPingFrame.Ping;
begin
Edit1.Text := 'Someone pinged me';
end;
And on the other end:
type
TPongFrame = class(TFrame)
...
public
procedure Ping;
end;
implementation
procedure TPongFrame.PingPongBtnClick(Sender: TObject);
begin
(Owner as TPingFrame).Ping;
end;
procedure TPongFrame.Ping;
begin
Edit1.Text := 'Someone pinged me';
end;
This is better than Method 1 as it allows both frames to change their controls without having to worryabout "outsiders" referencing them, but still has the drawback of the circular reference that can only be "solved" by moving one "use" to the implementation section.
It is a good practice to try and avoid circular references altogether instead of patching them by moving units to the implementation section's uses clause. A rule of thumb I use is:
Any form/frame may know and use the public interface of the forms/frames it instantiates (though it should avoid the controls in the "default visibility" part of that interface), but no form/frame should not have any knowledge of the specific form/frame that created it.
Method 3
One way of achieving this (there are many) it to use events just like the TButton's OnClick event.
On the TPongFrame side of things you can remove the use of Ping_fr. You no longer need it.
Then you need to declare a property and the field it references and declare a method to fire the event.
type
TPongFrame = class(TFrame)
private
FOnPingPongClicked: TNotifyEvent;
protected
procedure DoPingPongClicked;
public
property OnPingPongClicked: TNotifyEvent
read FOnPingPongClicked write FOnPingPongClicked;
end;
The Ping method stays and its implementation is unchanged. The PingPongBtnClick event handler also stays, but its implementation now becomes:
procedure TPongFrame.PingPongBtnClick(Sender: TObject);
begin
DoPingPongClicked;
end;
procedure TPongFrame.DoPingPongClicked;
begin
if Assigned(FOnPingPongClicked) then
FOnPingPongClicked(Self);
end;
You could put the code from DoPingPongClicked straight in here, but it is a good practice to fire an event in a separate method. It avoids duplicating the exact same code if you would have an event that can be fired from multiple parts of your code. And it also allows descendants (when you get those) to override the "firing" method (you'll have to mark it virtual in the ancestor) and do something specific all the times the event is fired.
On the TPingFrame side of things you need to code a handler for the new event:
type
TPingFrame = class(TFrame)
...
protected
procedure HandleOnPingPongClicked(Sender: TObject);
Note that the signature of this handler needs to be what the TNotifyEvent specifies. And of course you need to ensure that this event handler gets called when the event fires in TPongFrame:
procedure TPingFrame.CreateChildBtnClick(Sender: TObject);
begin
CreateChildBtn.Enabled := False;
FPong := TPongFrame.Create(Self);
FPong.Parent := ContainerPnl;
FPong.Align := alClient;
// Listen to event fired by PongFrame whenever it's PingPingBtn is clicked
FPong.OnPingPongClicked := HandleOnPingPongClicked;
end;
In the handler code you can do what you need to do. It can be general:
procedure TPingFrame.HandleOnPingPongClicked(Sender: TObject);
begin
Edit1.Text := 'OnPingPongClicked event was fired';
end;
And of course you can also use the fact that the event passes a reference to the instance firing the event as well:
procedure TPingFrame.HandleOnPingPongClicked(Sender: TObject);
var
Pong: TPongFrame;
begin
// This checks that Sender actually is a TPongFrame and throws an exception if not
Pong := Sender as TPongFrame;
// Use properties from the Pong instance that was passed in
Edit1.Text := 'OnPingPongClicked event was fired by ' + Pong.Name;
end;
Enjoy!
is it posible to create runtime frame and add existing panels like setting the parent of panel to the frame? and when it added, dulplicate the frame and use it?
like:
f:= Tframe. create(..)
...
panel3.parent = f; //where panel3 has many controls.
then duplicate the f? was it posible? how? or any other suggerstion?
e
I don't think you would solve this by duplicating. What you need is a function like this:
function CreateFrameAndHostPanel(Owner: TComponent; Parent: TWinControl; Panel: TPanel): TFrame;
begin
Result := TFrame.Create(Owner);
Try
Result.Parent := Parent;
Panel.Parent := Result;
Except
FreeAndNil(Result);
raise;
End;
end;
You need to remember that all controls have a parent and an owner. Owners could be nil but then you need to free those controls through code, so most controls are owned by some other component.
Thus, if the owner gets destroyed, the panel would be destroyed too. And if the panel was created in design-time then it's owned by the form that it's on!
Destroying that form would destroy the panel!
But if you create the panels in runtime and set Application as owner instead of a form, they could be moved over multiple forms and frames.
But is it a good design pattern? I don't know what you're trying to do but it's likely a bad idea!
In general, it would be more practical to design the whole frame with panels in design-time. Then add some code that would allow the frame to be created by copying data from another panel or control. That would be a better design pattern...
You must create the new frame (FRAME2) with the same code that you have used to create the first (FRAME1); And later, you must create all the component included (created on runtime) inside FRAME1 on FRAME2.
For to this, use:
for i := 0 to (FRAME1.ComponentCount - 1) do
...
cmp := TComponent(FRAME1.Component[i]);
... create cmp on Frame2
You can try a second alternative; Save the FRAME1 using a TMemoryStream (SaveComponent) and later create the new Frame and retrieve the saved information on Stream (I don't have test this option).
Regards.
What's so special with Frames that when you create them run-time it gets assigned a name automatically ? This causes a problem when you use them in a loop i.e. :
for i := 0 to 3 do
TMyFrame.Create(self); //Error on 2nd pass
On first pass, the frame is explicityl named 'MyFrame'.
On second pass, it will try to name it again 'MyFrame' which
obivously will cause an exception as there is already a
component with such name.
The other components or forms are happy to be created without
me assigning them a name. What gives ?
This is on Delphi 2006 btw.
Cheers
If you are using TFrame to create your Frame, then it wont raise that error.
i.e., If your code looks like this, you wont have any problems
for i := 0 to 3 do
Frame1 := TFrame.Create(self);
because here the Name property is unassigned. If you want you can check by using the statement ShowMessage(Frame1.Name);
But if you use TMyFrame i.e., the frame which you derived from TFrame, then it will giving the problem.
I think the reason is, Delphi was explicitly assigning the same Name every time you create the TMyName.
you're trying to create the same frame 4 times, each time you create the frame it will have the same name, one way to avoid is
...
var
i: Integer;
lFrame: TFrame;
begin
for i := 0 to 3 do begin
lFrame := TFrame.Create(Self);
// assign a unique name to the frame
lFrame.Name := Format('MyFrame%d', [i]);
// set the parent, align, etc...
end;
end;
Co-incidentally I just bumped into this myself (again).
If you take the name out of your frame component then Delphi moans that "Root Component must have a name" - I guess it because somewhere Delphi is calling RegisterClass(RootComponentName) and then to create it (or a descendent) it's calling Findclass(RootComponentName) or similar. As you can do this yourself to create components that you don't actually know the classname of a design time, why would Delphi not do the same?
Whereas with a TButton etc. it is already a registered Class.
I need to run an action that is attached to a button (say SQLBtn) that is placed on a Frame1 within my app, from Form1.
I have included the frame in Form1 uses, but can't seem to address in any way.
I've tried Frame1.SQLbtn TFrame1.SQLbtn TFrameSQLBtn etc but can't get to it.
I would like to get to something similar to 'SQLbtn.click' to run the event behind it.
Does any one have any ideas how to address it?
I am not sure I understand your question correctly. Sounds like you have a frame with a button (and either an TAction or click event handler on the button) and this frame is sitting on a form. Now you want to programmatically simulate a click on that button.
Obviously you need to add the frame unit to your form's uses clause. You also need an instance of the frame on the form which should lead to a form field of the frame type, e.g.
TForm1...
...
Frame1: TFrame1;
end;
Then you can execute that code via Frame1.SQLbtn.Click from within any of the form's methods. A better way would probably be to provide a public method on the frame which you can use from the form. Then you don't need to access the button directly (the button is an implementation detail of the frame, frame private so to speak).
Edit after clarification
I understand you have the following scenario:
TFrameForm1...
...
Frame1: TFrame1;
end;
TForm1...
...
procedure something;
end;
procedure TForm1.something;
begin
// how to call a method on Frame1 which is on FrameForm1
end;
Your best choice is to move the code from frame button OnClick event handler into a separate unit. This can be a datamodule, or a just another unit with a standalone procedure. Then you can call that code from both Form1 and the Frame1 button event handler. This is what Vegar has commented.
If that is not possible, e.g. because the processing requires access to other controls on Frame1, move the code into a new procedure on Frame1 (my original suggestion):
TFrame1...
...
public
procedure framestuff;
end;
procedure TFrame1.framestuff;
begin
...
end;
procedure TFrame1.SQLbtnClick(Sender...);
begin
framestuff;
end;
Now you need to call that method from Form1. You'll need a reference to FrameForm1 for that. Which you need to initialize manually (!) when you create TFrameForm1. In this example, the reference is a field FFrameForm:
TForm1...
...
FFrameForm: TFrameForm1;
procedure something;
end;
procedure TForm1.something;
begin
FrameForm.framestuff;
end;
Or, by default Delphi adds global variables for all forms to the form units (auto form creation, check project options / forms). Then you do this:
procedure TForm1.something;
begin
FrameForm1.framestuff; // if FrameForm1 is the name Delphi used for the global variable
end;
Of course there are many other variations...
procedure TDiferentForm.DoSomething();
begin
Form1.YourFrame.ButtonClick(nil);
end;
One thing that might help you understand: when you create an instance of a form (or frame), delphi goes through the DFM and creates instances of all the objects described there.
IF you have a variable in the form's definition that matches the name of the object in the DFM, the loader will make the variable point to the object; if you don't have a variable, the object is created but you would have to iterate through .Components or .Controls to get to it.
If the form has an instance variable of the frame (and that variable is public), then any other form's code can access it (e.g. MainForm.Frame1...) and do what it wants to.
To encapsulate the frame, the form (which is, after all just a class) can have public properties that have accessors and mutators to proxy the information to and from the embedded frame. Encapsulation is good (IMHO the most important aspect of OOP) because it makes the link between the caller and the frame loose: you can change either side a lot without breaking things.
Cheers
Another solution is to use interfaces to avoid the circular reference problem and simplify the code a bit. Lets say that you have a procedure named foo that you want to invoke from anyplace in the system. The implementation of this procedure is in tFooForm which is not the main form, but a form that the main form knows about.
First create a new unit and call it Foo_Intf.pas
Its contents will be the following:
unit Foo_Intf;
interface
type
IFoo = interface
['{4AC12AB9-557B-4E61-AB2D-8B10E591E33A}']
// CTRL-SHIFT-G to create a new guid
procedure Foo;
end;
implementation
end.
then add the method to the tFooForm class, and also include the interface. Don't forget to use the foo_intf.pas unit in your interface uses clause. Implement the foo class to do what ever you want that procedure to perform.
tFooForm = class(tForm,IFoo)
:
procedure Foo;
:
end;
Also add the IFoo interface to the main form, exactly like the previous step but change the implementation to be the following:
procedure tMainForm.Foo;
begin
if not Assigned(FooForm) then
FooForm := tFooForm.Create(Application); // for simplicity sake
FooForm.Foo;
end;
Now, anyplace you want to call the foo function, just include ONLY the Foo_Intf unit in the uses clause and use the following snippit:
var
FooIntf : IFoo;
begin
if Not Supports(Application.MainForm, IFoo, FooIntf) then
Raise Exception.create('Application.mainform does not implement IFoo');
FooIntf.Foo;
end;