Use event (VB. NET) correctly)

Original SourceBy ninputer

I. How to define and trigger events

There are two syntaxes for defining events. One is to explicitly specify the delegate type of the event processing method:

[Modifier] EventEventnameAsHandlertype

The other is to write the event processing method parameters directly in the Definition Statement, which is a method that implicitly specifies the delegate type:

[Modifier] EventEventname(ARGs)

In this definition, VB generates a nested defined delegate type based on the parameter table. I recommend that you use the first definition method in most cases, because the first method can independently delegate the event processing method to prevent accidental creation of a large number of waste types. For example, the following two events:

Public event test (byval sender as object, byval e as eventargs)
Public event test1 (byval sender as object, byval e as eventargs)

These two events have the same parameter structure, so their delegate types should be the same. However, VB is not smart yet, and the two statements will generate two different Delegate types. Further, the processing process of this parameter has been defined by the system as system. eventhandler, so there is no need to create any new delegate type, just write as follows:

Public event test as eventhandler
Public event test1 as eventhandler

There is only one situation where you can define an event in the form of a parameter table at will, that is, when the event is defined in the interface. For example, the interface has this event:

Public interface itest
Event test as eventhandler
End Interface

The event definitions that implement this interface can be written

Public event test (byval sender as object, byval e as eventargs) implements itest. Test

There will be no new delegate type here, because VB can determine that the event Delegate type comes from the interface definition. Another benefit of defining an event by displaying the specified delegate type is to make the code for using this event in C # concise.

In terms of triggering events, many beginners of VB use raiseevent everywhere to trigger events, which is very incorrect. Events should always be raised in a protected virtual method called onxxx (XXX is the name of the event. For example, to trigger the test event in the above example, you should write a method like this:

Protected overridable sub ontest (E as eventargs)
Raiseevent test (Me, E)
End sub

Call the ontest method to trigger the event where the event is actually needed. Why? Only in this way can this type of subclass be allowed to control the behavior of this event. If this is not the case, the subclass will not be able to know when the parent class will trigger the event, and will not be able to execute custom code when the event is triggered. As to why it must be named onxxx, this may be the same convention of the. NET class library. You must get used to this writing method. In further development, we will gradually find the idea of this writing method.

Ii. Design of event parameters

We can see that the object events in the. NET class library always provide an object-type parameter sender and a xxxeventargs-type parameter E. This is a unified design of the entire. NET Framework. Xxxeventargs is a type that inherits from system. eventargs. It indicates the data passed through the event, and sender indicates the event sender. When designing event processing methods, if there are no special cases, we should always provide two parameters: one sender parameter and one parameter that inherits the eventargs type. This design maximizes the similarity of signatures in all event processing processes. You will find that when your design needs change, this design can minimize the overall modification of the system. For example, if the event is designed as follows:

Event myevent (sender as object, index as integer, product as string)

When the demand changes and another price parameter of the decimal type needs to be passed, it will be a disaster to add a parameter to all processes in the system to respond to this event. If You encapsulate all the data to be passed in a type inherited from eventargs-myeventargs, the code can be written as follows:

Event myevent (sender as object, e as myeventargs)

When the requirement changes, you only need to modify the member of myeventargs. The method definition of the response event does not need to be changed.
In most cases, parameters are not required for an event. Therefore, the system. eventhandler defined by the system is a good choice, and there is no need to write a new eventhandler or eventargs type for each event.

If you need to pass back parameters through the event (that is, the event processing method must pass some data to the event sender), you can also use the parameters of the processing method to complete the process, you only need to set the attributes to be returned in the Custom eventargs type to writable (set accessors are provided. In general, we do not need to design byref parameters as suggested in some textbooks to implement callback. This is because eventargs can meet most of the design requirements.

As for the sender parameter, the caller should always pass the me variable so that the event handling method can correctly identify the event sender.

Conclusion

Event design is an important part of object-oriented design. A well-designed event usually includes explicitly specifying the delegate type of the event processing method. Generally, the system is used. eventhandler uses the protected virtual method named onxxx to trigger events and use custom data inherited from eventargs to wrap events.