Instead of adding an event field to the control class, we reuse a mechanism
given to all controls from the System.Web.UI.Control base class.
The Events read-only property inherited from the Control class provides access to an
event collection of type System.ComponentModel.EventHandlerList. EventHandlerList provides
access to delegates that represent the invocation list for each event the control exposes. This
means that the only memory taken up to handle event delegates is by those events that have a
client event handler method registered, unlike the previous technique, which takes a hit for
each event, regardless of any clients using it. This can potentially save a fair amount of memory
on a control that exposes many events. Figure 5-12 graphically depicts the benefits of using the
Events collection.
Figure 5-12. The difference between using an event field and using the Events collection
210 CHAPTER 5 ?– SE RVER CONTROL EVENTS
The first thing we need to do for an event using this new model is provide a key for the
delegate that is used to store it inside the Events collection. We add this at the top of our class
by creating a generic static, read-only object to represent the key for our click-related delegate:
private static readonly object ClickEvent = new object();
The second step is to use the syntax C# provides for custom delegate registration with our
Click event.
Pages:
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311