I have been learning Delphi for the last 3 years, on a hobby/occupational level. I am happy to say that I have now progressed to the point that I can look back on my early code with horror and embarrassment. So I am now going through some of my early apps and rewriting/ refactoring them.
One of the bad habits I am trying to get away from is accessing components on one form from another unit. In an effort to enforce this, I have been experimenting with using frames as a method of information hiding. So instead of having a form with components on it, I am creating a frame to hold all the form components, then placing the frame on a form, moving the frame declaration into the private declarations,
type
TMyForm = class(TForm)
private
MyFrame: TMyFrame;
procedure SetTimeDate(const Value: TMyItem);
function ReadTimeDate:TMyItem ;
then registering the frame in the form initialization section
initialization
begin
RegisterClasses([TMyFrame])
I am then declaring the properties I need in the public section of the form unit, which has access to the frame and its components.
public
property TimeDate: TOverlayItem read ReadTimeDate write SetTimeDate;
I am also using frames to consolidate often repeated component groups.
This seems to work for the purposes I want (hiding Myframe and its components), but does anyone else have any experience of this method?
Are there any drawbacks with using frames?
Am I actually gaining any benefit from doing this?
Are there any problems with using nested frames within frames?
Are there any good practice guides to using frames in Delphi?
Are there better/ easier ways of achieving the same effect with regard to GUI information hiding in Delphi?
HMcG
It sounds like you are still having a lot of logic in your UI layer. Forms/Panels shouldn’t have that much Value properties (except maybe for Dialogs).
If you want more structure than read up on the MVC pattern.
Having said all that, Frames can be a good way to organize the GUI. Like with everything, don’t overuse.