Frames originally emerged as a way to dynamically create multiple sets of visual objects, grouped together, positioned in a certain way, and once customized. For example, a group of a pair of input elements (EditBox), a checkbox (CheckBox) and a button can be combined in one frame, after which the required number of such groups can be created on the parent scroll box to manage many such objects. In this case, all groups will look and function the same.

 

It makes sense to talk about this component only in the context of the Mirror Classes Kit. A frame during design time is a form on which other visual and non-visual components can reside. To organize a frame, unlike a form, put a TKOLFrame component on a Delphi form instead of a TKOLForm object.

 

But unlike a form, at runtime, a frame is a panel that can be created on an existing form or other parent visual that allows children (for example, a scroll box created by calling NewScrollBox or another panel). In this case, the function for creating a frame generated by the MCK components actually creates a panel, and all child elements of the frame, in accordance with what was specified at the design stage.

 

Accordingly, a frame should be created immediately as a child of the object on which this frame is supposed to be located. For example:
 
NewfrmMyFrame (MyFrame1, Panel1);

 

This call positions the frame to be created on Panel1 by assigning the pointer to the frame to be created in the variable MyFrame1. The type of the variable MyFrame1 must be PfrmMyFrame, and like the form in MCK, it is not the created panel itself, but provides a container object for this panel and its children. The frame panel itself becomes available through the Form field.

 

It looks, perhaps, a little confusing, but in fact, this is practically the only possible option. Indeed, after creating a frame, in order to provide some features of its functioning, the code will also need to refer to its elements. For example, if frmMyFrame contains Panel1 and EditBox1, then you should use the compound names MyFrame1.Panel1 and MyFrame1.EditBox1 to refer to these objects in your code. In light of the above, it is easy to draw a parallel with the form and it becomes clear that the frame panel itself as an object of the PControl type should be available to the programmer exactly as MyFrame1.Form.

 

Note that you yourself create (declare, use) the MyFrame1 variable, MCK does not do this for you. The explanation is simple. It is entirely up to you where such a variable is located, whether it is a global, local, form field, or in general you store a list of such pointers in an object of the PList type or in object string pairs of the PStrListEx object. Or maybe you are not going to save a pointer to the frame at all, and after creating it and specifying some initial settings for it, it continues to live its own life (until the death of the parent visual object).

 

Just in case, make sure that the Delphi form on which the TKOLFrame is located instead of the TKOLForm is not included in the list of automatically generated forms. The function call is supposed to be NewfrmMyFrame you will do it yourself, in the place of the code where you need it.

 

If it is necessary to terminate the existence of a frame before the expiration of the parent's lifespan, then proceed in the same way as with the form: MyFrame1.Form.Free... And, of course, do not forget to reset the MyFrame1 variable for yourself, or in some other way ensure the impossibility of accessing a no longer existing object in the application code.