This chapter is from the book
This chapter is from the book
This chapter is from the book
Defining Delegates
The procedure for defining new delegates is very similar to declaring subroutines and functions, except without the function and subroutine body. The key to defining delegates is to decide whether you need a function or a subroutine and what information you want to pass to the handler procedure.
From the signature of the existing EventHandler delegate, we can derive the EventHandler declaration as stated previously:
Delegate Sub EventHandler( ByVal sender As Object, _ e As System.EventArgs )
Suppose you wanted a delegate that defined a function taking two string arguments and returning a Boolean. Perhaps you would use this to define comparison behavior; you would define the delegate as follows:
Delegate Function Compare(ByVal Str1 As String, _ ByVal Str2 As String ) As Boolean
After you have determined the signature of the Delegate type and declared the delegate, it's simply a matter of defining procedures matching those signatures and assigning the address of those procedures to Delegate instances.
Declaring Procedures That Match Delegate Signatures
Continuing our example from the beginning of this section, the values of Delegates are the addresses of procedures. Using the Delegate Compare as a further example, any function taking two string arguments and returning a Boolean could be assigned to compare delegates:
Function Ascending( ByVal Str1 As String, _ ByVal Str2 As String ) As Boolean Return Str1 > Str2 End Function
The rule is that the signature must match. The signature is made up of the type of procedure (function or subroutine), the argument-passing convention and types, and the return type for functions. As demonstrated by the function Ascending, the function name can be anything. Although not demonstrated here, the argument names can be anything as long as their types, order, number, and passing conventions are identical.
Initializing a Delegate
Delegates are initialized by assigning the address of a suitable procedure to a Delegate instance. Continuing our example, a Delegate of type Compare would be declared as follows:
Dim MyCompare As Compare
To initialize MyCompare (we could have done it on the same line as the Dim statement), we can assign it to the address of the Ascending function:
MyCompare = AddressOf Ascending
After we have the Delegate initialized, we can invoke the referenced procedure by treating the delegate as if it were the procedure. MyCompare( "one", "two" ) returns False because the string "one" isn't greater than the string "two".
Motivation for Using Delegates
If this and the previous chapter are your first exposure to events and procedural types, you might be wondering why we would do any of these things. For example, why not simply call the Ascending function directly? The answer is easy. At the time we write the code, we may have more than one procedure that makes sense based on the state of the program, which is only known at runtime.
Consider the sorting example again. Suppose the user wants to sort a list in ascending order. We could write conditional code that reads algorithmically if user wants an ascending sort, call the ascending sort function, else call the descending sort function. Notice, however, that this implies two functions. We really only want one function. Hence, someone might suggest that we add an If conditional and a flag. Revising the algorithm to accommodate the flag and conditional code, we have this: if ascending, then set ascending flag, else set descending flag. For each element, if ascending, then compare ascending, else compare descending. The second implementation complicates the logic, and we would pay performance penalties for the If conditional check. Finally, if we simply pass the Compare procedure to the sort algorithm, whichever type of compare we need is the one that is used. Passing the address of the comparison function (as one example) means we have one function and no conditional code. Read the next section for an example of a sorting algorithm with dynamic comparison arguments.
That's all fine and good. A reasonable person might ask, "Do we have any other motivation for using delegates?" The answer is a resounding yes. Any time we can anticipate needing a procedural respondent but we won't know until runtime what will need a respondent, we need delegates. Consider the case where you are adding controls to your forms at runtime. These controls will need event handlers. You may be able to define the event handler while you are coding, but the object whose event it will be assigned to won't exist until the program is running. You will need delegates to manage this scenario.
Granted, passing procedural types and dynamically creating components aren't things you will do every day, but you are likely to create classes and controls that define events. Someone will be defining event handlers for those classes and controls, and they will need to assign the handlers to the Delegate properties.
Procedural types are an advanced aspect of programming that you may not use every day. However, when you need delegates, they will be there, and sometimes will be the best way to solve problems that can be solved in no other way. Experience and practice will ultimately be your best guides.