What is the point of using TFrame in the following example and in general ?
I was just looking at “App Settings Screens” sample that I downloaded from GetIt. There is a unit with a TFrame with a bunch of components. It’s used only in one form in this case. But, in a real application, this could only be used in one for form anyway. So how is the TFrame helping here. It seems to me that its made the code less maintainable in that if you change the Frame, you have to remember to add it to the Form again. Its using more resources and is going to take fraction more time to launch.
A guess here, but maybe it’s more about separating out related bit of functionality. On mobile, FMX kind of encourages you down this path of one form apps. A lot of the examples end up using tabcontrols with hidden tabs, and then swiping between the tabsheets.
This quickly becomes a pain in the bum with all you application code in a single unit. So sticking the contents of each tabsheet in it’s own frame at least lets you manage them separately.
That’s not how frames work. Any changes you make to the frame automatically flow through to any forms you have them hosted on.
That said most developers I know don’t place their frames on forms at designtime but rather they create and place them on the form at runtime.
You can do it at designtime and it does work pretty well (including having your changes automatically flow through) but there are a few minor niggles associated with designtime placement that make it a bit more robust to do it at runtime instead.
A single frame on a single form is probably unnecessary. Where frames come into their own is for user interfaces that are based on a TPageControl or some other screen switching device. Rather than having all the controls and code for that TPageControl in the one unit it lets you split each page/tab into a separate frame unit.
You get an almost identical outcome at runtime using forms in your pagecontrol tabs. Using TFrame instead though:
illustrates the intention of the unit more clearly to other developers
means you can place them on the TPageControl at designtime (though I don’t recommend it).
Basically you can do it either way but since that use case is a big part of what a TFrame is for I think the question is really why aren’t you using it rather than why should you use it.
When I started using forms I knew little about frames and found forms easy to use. I think one of my problems was that there was no OnFormCreate event (or similar), so I had to use the constructor. So I have been using forms ever since.
But I agree with first point that it ‘illustrates the intention of the unit more clearly to other developers’.
I dunno, I think I’d call the constructor “similar” to an OnFormCreate event. There’s also AfterConstruction to override if you don’t want to use the constructor for whatever reason.
Bottom line, I wouldn’t bother going back and changing old code that used TForms over to TFrames, but I’d definitely recommend using TFrame for any future pagecontrol style applications.
I use form inheritance quite a lot but I find that when I want to
create a form which is inherited from an existing form the list of
inheritable items contains all my forms and is not easily searchable (at
a guess I believe that the list in descending creation order).
Is there a way way to reduce the size of the list?
Is there a way way to reduce the sort of the list?
I believe that there is an option (static??) that can be applied to a
class to indicate that the class cannot be sub-classed. Perhaps this
could be used.
You’re thinking of sealed. I’ll be surprised if the IDE takes notice of that when building the list of potential ancestor forms, but I guess it’s worth a try.
There’s also AfterConstruction to override if you don’t want to use the constructor for whatever reason.