3
votes

Here is a quick comparison of Delphi components and frames and at the end is my question.

Advantages of Delphi components:

  • They are encapsulated well. A software that uses components can access only public and published properties of components.
  • All their inner event handlers are available at parent form's design time.

Disadvantages of Delphi components:

  • They need to be installed with some package
  • The package is shared between multiple applications even if the components inside are application-specific

Advantages of Delphi frames:

  • They could be placed on a form just like components
  • Their published properties also can be adjusted in a form
  • They are in-app only and aren't available for the rest of apps which they don't belong to
  • They are quickly available. No need to install.

Disadvantages of Delphi frames:

  • All of their inner components are directly available in a parent form. If I move the components from published section, design-time customizations are broken in the frame designer too.
  • If I override the Resize method in a frame all the arrangements are available at run-time only. No arrangements at design-time are made.
  • If I introduce a new published property, it is not available in object inspector.

What I would like to have is a symbiotic thing:

  • Good encapsulation. None of the inner components is available from the parent form, but all their inner components are fully functional either at run-time or at their design-time.
  • Quick availability. No need to install.
  • In-app only. No sharing with other apps.
  • Their published properties can be adjusted in a form
  • All the method overrides (especially Resize method) are available at design-time.

Could you suggest a thing that fulfills these requirements? Or may be some surprising method to work with frames I didn't know about?

It shouldn't be necessarily a frame or a component. If some of other VCL classes fulfills these requirements, I would gratefully accept it.

1
I always create the frames in run-time. Then you are always safe that noone modifies the inner components of your frame. But if you want it be available at design-time - there I see only custom component implementation which will store the class name of the frame to construct and via the class it can also iterate the properties.. - but that's something from the sci-fi movie and is too complicated. - Z.B.
I dont see why the second disadvantage of components is considered a disadvantage. - GuidoG
This reads like a feature request rather than a question. You know that the thing that you are asking for does not exist. - David Heffernan
@David Heffernan: Sorry, but I don't know this for certain. On my latest "feature request" several years ago people suggested me to try frames which I didn't know about at that time. - Paul
You want to introduce new properties that can be edited in the inspector, and that means that you have to use components that are provided by a design time package. That's it. There is nothing else. - David Heffernan

1 Answers

3
votes

If its properties have to be editable in the designer the object has to be a descendant of TComponent. TFrame actually is a descendant of TComponent.

Unfortunately, object inspector seems to use structure information from design-time packages only. Thus, you have to compile a design-time package for your custom published properties to show in object inspector. But that strikes your requirement of Quick availability.