Super components en Pascal

SuperComponents
How to Build Aggregate/Composite Components in Delphi™
Copyright © 1996, 1997 Mark Miller
Eagle Software
What are SuperComponents?
SuperComponents, also known as aggregate or compound components, are collections of existing subcomponents and their relationships combined into a single component. The collections are typically
arranged inside a container parent component that manages the visual layout of the sub-components.

Advantages
SuperComponents take all of the advantages of normal components and build on them. Rapid application
development, object reuse, and user interface consistency are all benefits. Code shrinkage is another. If
you have two or more forms containing similar component relationships (either inside an application or
among several), that component relationship is tied to each form with - you guessed it - code. That
binding Object Pascal code is duplicated with each form the component group lies on. By fusing the
component collections into a single component, the code to manage the sub-component relationships
disappears from the user interface code. The code for each form more truly represents its functionality; it's
easier to read and maintain.
Another benefit achieved through the use of SuperComponents is multiple form inheritance. You can take
parts of different forms (SuperComponents) and group them together into a new form. This leads to even
faster prototyping and user interface design than normally experienced with Delphi.
SuperComponents can simplify the properties needed to control the collection. Instead of dealing with
properties and events for each component in the collection, the SuperComponent only exposes the
properties and events it needs, thereby reducing the design-time complexity of the component.
As mentioned earlier, SuperComponents can embody the rules of the relationship among the
subcomponents. This relationship might represent an algorithm or solution to a problem, or it might
support state changes not present in any of the individual parts. Algorithm parameters and/or hooks to
state changes can be easily exposed through new properties and events.
Finally, SuperComponents can be thought of as mini-apps. They are components themselves, and as such,
lend themselves to a well-defined segregation from the rest of the project they are contained in. In team
development environments, this means that developers most familiar with the problem and solution
(whatever they be) can design the SuperComponents so that less-experienced developers can piece
together the application with these building blocks.

Disadvantages
There are two disadvantages to making SuperComponents. First, visual SuperComponents require an
additional Windows handle. Second, there is a small amount of overhead in the container parent
component that holds all the sub-components.

Before We Start
It is useful to distinguish among the different roles developers and users take when dealing with
components. There are three that we are concerned with:
•Application Users (a.k.a. "users") will use applications built with the components we make.
•Application Developers (a.k.a. "developers") will build applications using our components.
•Component Writers (that's us!) will create components that will make is easier for developers to build
applications and easier for users to use. It's important to note that as a component writer, you're designing
for two customers.

Visual Containment
The steps to building a SuperComponent are roughly as follows:
1.
2.
3.
4.
5.
6.

Design the layout of your components inside a form in Delphi, placing all the components inside a
TPanel (or a descendant thereof).
Select and copy the panel and paste it into a text file.
Replace all instances of " = " with " := ", and add a semi-colon to the end of each line.
Convert all DFM "object" declaration lines to appropriate object constructor code, setting the parent
of all visual controls to the container panel.
Clean up any remaining code. Bitmaps will need to be placed in resource files.
Place this new pascal code inside a create constructor for your component. Within the constructor ,
group object sections under the appropriate sub-component creator.

Let's use an example to illustrate these steps. We'll make an OK/Cancel/Help button combination. Inside
Delphi, the layout looks like this (Note: the TPanel's border is set to none):

Selecting, copying and pasting the above collection into a text file yields the following:
object Panel1: TPanel
Left = 114
Top = 10

Width = 75
Height = 95
BevelOuter = bvNone
TabOrder = 0
object OKButton: TButton
Left = 0
Top = 0
Width = 75
Height = 25
Caption = 'OK'
Default = True
ModalResult = 1
TabOrder = 0
end
object CancelButton: TButton
Left = 0
Top = 35
Width = 75
Height = 25
Cancel = True
Caption = 'Cancel'
ModalResult = 2
TabOrder = 1
end
object HelpButton: TButton
Left = 0
Top = 70
Width = 75
Height = 25
Caption = 'Help'
TabOrder = 2
end
end
This is the text representation of our SuperComponent group. Next, we need to convert this text to
something that looks a little more like Object Pascal:
object Panel1: TPanel
Left := 114;
Top := 10;
Width := 75;
Height := 95;
BevelOuter := bvNone;
TabOrder := 0;
object OKButton: TButton
Left := 0;
Top := 0;
Width := 75;
Height := 25;
Caption := 'OK';
Default := True;
ModalResult := 1;
TabOrder := 0;
end
object CancelButton: TButton

Left := 0;
Top := 35;
Width := 75;
Height := 25;
Cancel := True;
Caption := 'Cancel';
ModalResult := 2;
TabOrder := 1;
end
object HelpButton: TButton
Left := 0;
Top := 70;
Width := 75;
Height := 25;
Caption := 'Help';
TabOrder := 2;
end
end
Now we're getting closer to what we want. The next step is to transfer the panel initialization to the
component's constructor. We'll create the embedded controls here, too:
constructor TOkCancelHelp.Create(AOwner: TComponent);
{ Creates an object of type TOkCancelHelp, and initializes properties. }
begin
inherited Create(AOwner);
Width := 75;
Height := 95;
BevelOuter := bvNone;
TabOrder := 0;
OKButton := TButton.Create(Self);
OKButton.Parent := Self;
CancelButton := TButton.Create(Self);
CancelButton.Parent := Self;
HelpButton := TButton.Create(Self);
HelpButton.Parent := Self;
end; { Create }
The three buttons, OKButton, CancelButton, and HelpButton need to be declared as fields of our new
component. Our component's declaration looks like this:
type
TOkCancelHelp = class(TPanel)
OKButton: TButton;
CancelButton: TButton;
HelpButton: TButton;
private
{ Private declarations }
protected
{ Protected declarations }
public

{ Public declarations }
constructor Create(AOwner: TComponent); override;
published
{ Published properties and events }
end; { TOkCancelHelp }
Now let's take that converted DFM text and initialize the three buttons. Although you can do this inside
our component's constructor, some VCL sub-component initialization code depends on a windows handle
existing in its parent. At the time when our new SuperComponent is created (inside the Create
constructor), this handle does not yet exist. So we need to find a method we can override in the TPanel
that is called before the component is displayed and before its loaded method is called, but after a
windows handle is assigned to the TPanel. The CreateWindowHandle method is the best place to do this.
An override of this method, with the DFM initialization code inserted, looks like this:
procedure TOkCancelHelp.CreateWindowHandle(const Params: TCreateParams);
{ Calls inherited CreateWindowHandle and initializes subcomponents. }
begin
inherited CreateWindowHandle(Params);
with OKButton do
begin
Left := 0;
Top := 0;
Width := 75;
Height := 25;
Caption := 'OK';
Default := True;
ModalResult := 1;
TabOrder := 0;
end; { OKButton }
with CancelButton do
begin
Left := 0;
Top := 35;
Width := 75;
Height := 25;
Cancel := True;
Caption := 'Cancel';
ModalResult := 2;
TabOrder := 1;
end; { CancelButton }
with HelpButton do
begin
Left := 0;
Top := 70;
Width := 75;
Height := 25;
Caption := 'Help';
TabOrder := 2;
end; { HelpButton }
end; { CreateWindowHandle }
And the component declaration now looks like this:

type
OKButton: TButton;
CancelButton: TButton;
HelpButton: TButton;
private
protected
{ Protected declarations }
procedure CreateWindowHandle(const Params: TCreateParams); override;
public
{ Public declarations }
constructor Create(AOwner: TComponent); override;
published
end; { TOkCancelHelp }
Finally, we need to add a register method so we can place our new component onto Delphi's component
palette:
procedure Register;
begin
RegisterComponents('CDK', [TOkCancelHelp]);
end; { Register }

Exposing Sub-Component Properties
Grouping components together to create new SuperComponents is a pretty neat trick. One advantage is
that it allows you to isolate many of the grouped components' properties from application developers. In
fact unless you explicitly state otherwise, all of the grouped components properties will be hidden from
developers!
So how do you expose a sub-component property? You need to create two transfer methods that transfer
the sub-component's properties to the outside world.
For example, in our TOkCancelHelp component, it might be useful to expose the caption property so
application writers can change it (e.g., for application development in a language other than English).
Our transfer methods look a lot like the standard property Get and Set methods we're already familiar
with. Here's the declaration for the OK button's caption property:
type
.
.
.
private
procedure SetCaption_OKButton(newValue: TCaption);
function GetCaption_OKButton: TCaption;
.
.

.
published
property Caption_OKButton: TCaption read GetCaption_OKButton write
SetCaption_OKButton;
end;
These transfer methods pass the property values to and from the subcomponents. Their implementation
looks like this:
function TOkCancelHelp.GetCaption_OKButton: TCaption;
{ Returns the Caption property from the OKButton subcomponent. }
begin
result := OKButton.Caption;
end; { GetCaption_OKButton }
procedure TOkCancelHelp.SetCaption_OKButton(newValue: boolean);
{ Sets the OKButton subcomponent's Caption property to newValue. }
begin
OKButton.Caption := newValue;
end; { SetCaption_OKButton }
You may notice that there is no field variable for this property. All sub-component properties rely on the
sub-components themselves for storage. Also notice that unlike most Set methods, this one doesn't check
to see if the internal value is different from the passed-in newValue. We let the sub-component handle this
check if necessary.

Exposing Sub-Component Events
Just as you would need to expose a sub-component's properties, you might also need to expose its events.
The theory behind exposing sub-component events is similar to that used to expose properties. The
difference is that with events, we need to store the event handler in a field variable (just like we would for
a normal event). Additionally we have to hook in to any sub-componenent event that we want to make
available to our component users, which means creating our own event handler for it. Event handlers
must be assigned dynamically when the component is first created. The declaration for an exposed event
and the event handler that surfaces it looks like this:
type
.
.
.
private
FOnClick_OKButton: TNotifyEvent;
.
.
.
procedure Click_OKButtonTransfer(Sender: TObject);
published
.

{ TNotifyEvent }

.
.
property OnClick_OKButton: TNotifyEvent read FOnClick_OKButton
write FOnClick_OKButton;
end;
Here, Click_OKButtonTransfer acts as the event handler. Notice that its type, TNotifyEvent, matches the
expected type for the OnClick event (TNotifyEvent). The implementation for the transfer method looks
like this:
procedure TOkCancelHelp.Click_OKButtonTransfer(Sender: TObject);
{ Transfers the OKButton OnClick event to the outside world. }
begin
if assigned(FOnClick_OKButton) then
FOnClick_OKButton(Self); { Substitute Self for subcomponent's
Sender. }
end; { Click_OKButtonTransfer }

If you've triggered events before, you probably recognize this code. The if-clause checks to see if the event
is assigned (typically performed via the Object Inspector at design-time), and if so calls it, passing a
reference to itself (the SuperComponent) to the component user's event handler. So, the sub-component's
event is handled by our transfer method, which in turn passes the event to a component user's event
handler (that's right -- two event handlers for each event!). To hook up this chain of events, all we do is
dynamically assign the event transfer method to the sub-component's event. We do this in the overridden
CreateWindowHandle method:
begin
with OKButton do
begin
.
.
.
OnClick := Click_OKButtonTransfer;
end; { OKButton }
.
.
.

Hooking in to Sub-Component Events
Sometimes you want to respond to a sub-component event without exposing it. The steps involved here are
similar to those you'd follow to expose a sub-component event, except you don't declare the event (and you
don't need the corresponding event field variable).

type
.
.
.
private
.
.
.
procedure Click_CancelButtonHandler(Sender: TObject);
{ TNotifyEvent }
published
.
.
.
end;
The handler looks like this:
procedure TOkCancelHelp.Click_CancelButtonHandler(Sender: TObject);
{ Handles the CancelButton OnClick event. }
begin
{ Place your event-handling code here. }
end; { Click_CancelButtonHandler }
We glue it all together by dynamically assigning our handler to the sub-component event, just as we do
when we want to expose a sub-component event:
begin
.
.
.
with CancelButton do
begin
.
.
.
OnClick := Click_CancelButtonHandler;
end; { CancelButton }
.
.
.

Summary

SuperComponents promote consistency and reuse. They can embody commonly-used configurations of
controls, dramatically cutting development time and slashing code size. And the techniques involved here
are not difficult to master.

Recommended Reading
The following books were current at the time of this writing. Make sure you check for the most recent
edition.
Developing Custom Delphi Components
by Ray Konopka; edited by Jeff Duntemann
Coriolis Group Books
(800) 410-0192 or (602) 483-0192
http://www.coriolis.com
585 pages
ISBN 1-883577-47-0
This book is highly recommended if you need additional information on component building or building
business components. It is filled with useful information and excellent examples. The explanations are
clear and easy to understand. In addition, Ray Konopka’s TRzBusinessComponent, included with the
CDK, is presented and detailed in his book.

Secrets of Delphi 2 -- Exposing Undocumented Features of Delphi
by Ray Lischner
Waite Group Press
831 pages
ISBN 1-57169-026-3
This is an amazing book, packed with valuable information you can’t get anywhere else. Also contains
excellent coverage of property editors, component editors, and other advanced component-building topics.

The Delphi Magazine
Edited by Chris J G Frizelle
iTec Publishing
To subscribe in the UK:
Tel/Fax: +44 (0) 181 460 0650
Email: 70630.717@compuserve.com
To subscribe in the US:
Phone: (802) 244-7820
Email: 70602.1215@compuserve.com
This magazine consistently contains excellent technical articles on Delphi-related subjects. Also contains
a monthly column by Bob Swart (a.k.a. Dr. Bob) on component building in Delphi.

Design Patterns--Elements of Reusable Object-Oriented Software
by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
Foreword by Grady Booch
Addison-Wesley Publishing Company
395 pages
ISBN 0-201-63361-2
This book organizes and presents a catalog of proven object-oriented solutions for architecting complex
systems that you can apply to your own specific applications. These design constructs are labeled,
allowing your development team to share a common vocabulary. The CDK help file references two of the
design patterns in this book: the Proxy pattern and the Template Method pattern. The examples are in
C++, but the patterns apply to all programming languages.

Component Writer’s Guide
by Borland International, Inc.
(408) 431-1000
156 pages
The Component Writers Guide is a lean but important resource for learning about how to create working
components and to ensure that components you write are well-behaved parts of the Delphi environment.
The book guides you to writing components that fit in well with any Delphi application.

About the Author
Mark Miller is the lead software engineer at Eagle Software. Mark holds the primary vision for the
Component Developer Kit for Delphi (the CDK) reAct, a component testing tool for Delphi, as well as
several other Delphi add-ons currently in development. He has been programming in Pascal, Object
Pascal, and Delphi for nearly 16 years.
He can be reached at markm@eagle-software.com, or via CompuServe at 76043,2422.

Super components en Pascal

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Super components en Pascal (20)

More from Paco Miró (7)

Recently uploaded (20)

Super components en Pascal