end;

 If the Sender of the event is not one of the buttons, we must determine which button to click. This is where the Tag property and the Components array property come in. As you noticed in Figure 3, SpeedButton1 had a Tag value of 1. MainItem1 and PopupItem1 also have Tag values of 1. Therefore, if any of the menu items are selected, it''''s a simple matter of viewing their Tag values and transferring the event to the SpeedButton with the same Tag. This is handled in the SpeedButtonClick handler:

 for A := 0 to ComponentCount-1 do

   if Components[A] is TSpeedButton then

     with Components[A] as TSpeedButton do

      if Tag = TComponent(Sender).Tag then

 This code snippet scans the Components array and examines each component it finds. When a TSpeedButton is found, the code compares this object''''s Tag value with the Tag value of the object that originally fired the message. If the values are the same, then the code found the button that ultimately receives the event. Since the code has already determined that it''''s a TSpeedButton, this object''''s up/down state can now be toggled. Then, either the PushButton or ReleaseButton procedure is called with the selected SpeedButton passed as the parameter as follows:

 begin

  Down := not Down;

   if Down then

    PushButton(Self.Components[A])

   else

    ReleaseButton(Self.Components[A]);

end;

 This statement:

PushButton(Self.Components[A])

 calls the procedure PushButton, passing along the parameter:  

Self.Components[A]

 The PushButton procedure interprets this Self statement as the original Sender. The Self portion is required because we want to look at the Components property of Form1. Since the code uses a with statement to simplify readability, we must ensure that the code is viewing the correct Components property. In this case, SpeedButtons also have a Components property and without the Self qualifier, it will erroneously look there instead.

 The PushButton procedure is where the timesheet database would be updated or other functions would be performed. Since the previous procedure handled the bulk of the work, PushButton simply performs the actions necessary when the button has been pressed. Remember that SpeedButtonClick did not send the actual Sender parameter, but sent a modified one that points to the SpeedButton regardless of how the button was selected. SpeedButtonClick''''s other procedure call, ReleaseButton, is likewise called to handle whatever events should occur when the button is released.

 Conclusion

Alone, the Sender parameter is a simple return address, allowing functions to trace which component triggered their event. But used in conjunction with a few other properties, such as Tag and Components, Sender becomes a powerful tool for tracing and filtering program flow. This ability to work around program limitations allows developers to create single, modular event handlers for components of all types, without the need for multiple if..then statements. This, of course, is just one way of extending Sender''''s abilities. There are as many possibilities as there are programs to write.

上一页  [1] [2] [3]