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:
文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
