|
Return to Sender
The Lowly Sender Parameter Can Make Applications Shine
The humble Sender parameter could be one of Delphi''''s most useful tools for modular, extensible programming. Although Sender is normally used to simply determine which object called a particular procedure, with some creativity, this parameter can be extended to allow robust modular programming with simple, reusable code.
Sender Basics
The Sender parameter is so ingrained in Delphi programming that it appears in practically every program procedure. Even the Form''''s OnCreate event - which has no sender - includes the (Sender: TObject) parameter in its definition.
Despite its ubiquity, the Sender parameter is not necessary for a procedure to function. Removing Sender from a procedure that doesn''''t use it results in perfectly functional code, as long as the parameter is also removed from the procedure''''s type statement in the form object''''s interface section. Delphi will generate an "incompatible parameter" warning at compile time, but this can be safely ignored. In fact, removing any unused Sender parameters results in slightly leaner and meaner code.
Not only can Sender be omitted from any procedure, but when used, it doesn''''t even have to be called Sender. This name is only used by convention. The common term makes understanding code simpler, but there''''s no reason not to name it Caller, Origin, or Banana if the developer prefers.
So the Sender parameter doesn''''t have to be called Sender, and is, in fact, unnecessary. So what is it? And why is it important enough to add to practically every Delphi procedure?
Sender is simply a parameter passed from the component that called the event handler. Sender (or whatever it''''s called by the event handler) is a parameter of the type TObject. Because TObject is the ancestor of all components, Sender can accommodate any Delphi object that can possibly trigger an event. Sender forms a two-way link between an object and an event handler; it tells the procedure what object triggered it to be called. In other words, if an event handler was a letter, the Sender parameter would be the return address.
Using Sender
The simplest and most common way to use Sender is with an if...then or case statement that performs a certain action depending on what object triggered the procedure. Here''''s a typical example:
procedure Form1.ButtonClick(Sender: TObject);
begin
if Sender is StopButton
then Stop(Sender);
end;
This code examines the Sender parameter to see if it''''s the object, StopButton. If so, the event handler calls another procedure, Stop, passing the Sender parameter to that procedure as well. The Stop procedure can call another procedure and so on, passing the Sender parameter through the program code. Because each procedure is simply passing along the parameter it received, wherever the parameter is ultimately used, it will reflect the object that called the original event handler.
Not only can Delphi developers use Sender to identify the object that called a procedure, but they can also use it to access that object''''s properties. The form in Figure 1 uses a number of colored panels as a palette. When the user clicks on a panel, the large panel on the left changes to the color of the selected panel.
Figure 1: This mini-program sets the color of the panel at right to the color of the panel selected by the user.
This procedure does not need the name of the panel selected, only its color property. Therefore, each panel in the palette can have its own color, but all share the following OnClick event handler:
procedure TForm1.Panel1Click(Sender: TObject);
begin
Panel1.Color := TPanel(Sender).Color;
end;
Since Sender provides a "return address" to the calling object, that object''''s properties can be read and set as well. This way, the procedure can also change the panel''''s Color property without actually working with the panel object''''s name. For example:
TPanel(Sender).Color := clRed;
Any type of property can be accessed using this framework, provided it''''s a property belonging to the specified type. In the previous example, the procedure specifies that Sender is a TPanel, which therefore has a Color property. While Sender is declared as a TObject in the procedure header, the following line would return a compiler error.
TPanel1.Color := TObject(Sender).Color;
As TPanel''''s ancestor type, TObject is perfectly valid in other respects; but it does not contain a Color property. Since TObject contains no properties, developers cannot use it to determine the properties of a wide range of objects. This means a program cannot find the color of a TPanel, TLabel, or TForm all with the same TObject(Sender).Color code.
In fact, these three component types all contain the Color property. However, because they do not share this property in common ancestor classes, programmers cannot easily create one block of code to get the Color property from these various types of objects. The simplest solution a developer could use would be this:
if Sender is TPanel then
Brush.Color := TPanel(Sender).Color;
if Sender is TLabel then
Brush.Color := TLabel(Sender).Color;
if Sender is TForm then
Brush.Color := TForm(Sender).Color;
Fortunately for developers, the Delphi designers added the Tag property. Tag is a little catch-all integer parameter that developers can use for whatever purpose they choose. What makes Tag especially useful is that it resides well up the inheritance tree in the TComponent class. Just two steps down the ladder from TObject, TComponent is the ancestor of all controls. This means that any of these objects will have the Tag property. Unlike the Color property cited above, the Tag property of any object can be accessed with a simple line of code:
TForm.Tag := TComponent(Sender).Tag;
Sender Impostors
I mentioned earlier that as procedures pass the Sender parameter from one to another, it never changes. It always points back to the object that called the original event handler. This is true provided each procedure along the path passes the original parameter. However, you can also substitute another parameter for the original Sender, fooling subsequent procedures into acting on another object as if it were the true Sender.
This is the basis of our sample application, SENDER.DPR. It uses Sender and the Tag property so that Delphi can be "fooled" into having similar menu and button commands perform special actions on the buttons. Traditionally, this wouldn''''t require special Sender parameters - both buttons and menu items will share an event handler that can update the button as part of its functionality:
procedure Button1Click(Sender: TObject);
begin
{ Main functionality }
Button1.Font.Style := [fsBold];
end;
However, when several components share a single event handler, the programmer cannot simply assume to act on a specific object. Modifying the code in question to read:
TButton(Sender).Font.Style := [fsBold];
is fine provided the code is alway [1] [2] [3] 下一页 | 
