While a class B is asked to provide some values to, or perform some assignment(s) for, another class A, many things would happen. In fact, there is an order that the actions should follow. For example, during the lifetime of a program, that is, while a program is running, a class may be holding a value it can provide to its client but at another time, that value may not be available anymore, for any reason; nothing strange, this is just the ways it happens. Because different things can happen to a class B while a program is running, and because only class B would be aware of these, it must be able to signal to the other classes when there is a change. This is the basis of events: An event is an action that occurs on an object and affects it in a way that its clients must be made aware of.
An event is declared like a pseudo-variable but based on a delegate. Therefore, to declare an event, you must have a delegate that would implement it. To actually declare an event, you use the Event keyword with the following formula:
[modifier] Event Name(Argument) As Type
The modifier can be Public, Private, Protected, or Friend. The Event keyword is required. It is followed by the name of the delegate that specifies its behavior. If the event as arguments, enter them in its parentheses. The declaration of an event must specify its type, and the type must be a delegate.
Here is an example that declares an event:
Imports System.Drawing Imports System.Windows.Forms Module Exercise Private Delegate Sub Display() Public Class Starter Inherits Form Private Event Evidence As Display Dim components As System.ComponentModel.Container Public Sub New() InitializeComponent() End Sub Public Sub InitializeComponent() End Sub End Class End Module
When the event occurs, its delegate would be invoked. This specification is also referred to as hooking up an event. As the event occurs (or fires), the procedure that implements the delegate runs. This provides complete functionality for the event and makes the event ready to be used.
Before using an event, you must specify the procedure that will carry the event. This procedure is referred to as a handler. Obviously you must first have created a procedure. Here is an example:
Imports System.Drawing Imports System.Windows.Forms Module Exercise Private Delegate Sub Display() Public Class Starter Inherits Form Private Event Evidence As Display Dim components As System.ComponentModel.Container Public Sub New() InitializeComponent() End Sub Public Sub InitializeComponent() End Sub End Class Private Sub Viewer() MsgBox("The Viewer") End Sub End Module
To add a handler to the program, you use the AddHandler operator with the following formula:
AddHandler EventName, AddressOf Procedure
The AddHandler and the AddressOf operators are required. The EventName placeholder is used to specify the name of the event that is being dealt with. The Procedure factor is the name of the procedure that will implement the event. Here is an example:
Imports System.Drawing Imports System.Windows.Forms Module Exercise Private Delegate Sub Display() Public Class Starter Inherits Form Private Event Evidence As Display Dim components As System.ComponentModel.Container Public Sub New() InitializeComponent() End Sub Public Sub InitializeComponent() AddHandler Evidence, AddressOf Viewer End Sub End Class Private Sub Viewer() MsgBox("The Viewer") End Sub End Module
After adding a handler for the event, it is ready but you must launch its action. To do this, you can use the RaiseEvent operator with the following formula:
The RaiseEvent operator is required. The EventName placeholder is used to specify the name of the event, and it must be followed by parentheses. Here is an example:
Imports System.Drawing Imports System.Windows.Forms Module Exercise Private Delegate Sub Display() Public Class Starter Inherits Form Private Event Evidence As Display Dim components As System.ComponentModel.Container Public Sub New() InitializeComponent() End Sub Public Sub InitializeComponent() AddHandler Evidence, AddressOf Viewer RaiseEvent Evidence() End Sub End Class Private Sub Viewer() MsgBox("The Viewer") End Sub Function Main() As Integer Dim frmStart As Starter = New Starter Application.Run(frmStart) Return 0 End Function End Module
The event we used in the previous sections did not take any argument. Just like a delegate, an event can take an argument. The primary rule to follow is that both its delegate and the procedure associated with it must take the same type of event. The second rule is that, when raising the event, you must pass an appropriate event to it. Here is an example:
Imports System.Drawing Imports System.Windows.Forms Module Exercise Private Delegate Sub Display(ByVal Message As String) Public Class Starter Inherits Form Private Event Evidence As Display Dim components As System.ComponentModel.Container Public Sub New() InitializeComponent() End Sub Public Sub InitializeComponent() Dim m As String m = "Welcome to the wornderful world of events" AddHandler Evidence, AddressOf Viewer RaiseEvent Evidence(m) End Sub End Class Private Sub Viewer(ByVal msg As String) MsgBox(msg) End Sub Function Main() As Integer Dim frmStart As Starter = New Starter Application.Run(frmStart) Return 0 End Function End Module
Just like an event can take an argument, it can also take more than one argument. The primary rules are the same as those for a single parameter. You just have to remember that you are dealing with more than one argument. Here is an example:
Imports System.Drawing Imports System.Windows.Forms Module Exercise Private Delegate Sub Description(ByVal Name As String, _ ByVal Salary As Double) Public Class Starter Inherits Form Private Event Recorder As Description Dim components As System.ComponentModel.Container Public Sub New() InitializeComponent() End Sub Public Sub InitializeComponent() Dim FullName As String Dim HourlySalary As Double FullName = "Paul Bertrand Yamaguchi" HourlySalary = 24.55 AddHandler Recorder, AddressOf ShowRecord RaiseEvent Recorder(FullName, HourlySalary) End Sub End Class Private Sub ShowRecord(ByVal id As String, ByVal wage As Double) MsgBox("Employee Name: " & id & vbCrLf & _ "Hourly Salary: " & CStr(wage)) End Sub Function Main() As Integer Dim frmStart As Starter = New Starter Application.Run(frmStart) Return 0 End Function End Module
Instead of a parameter of a primitive type, you can create an event that takes a class as argument.
An application is made of various objects or controls. During the lifetime of an application, its controls regularly send messages to the operating system to do something. These messages are similar to human messages and must be processed appropriately. Since most of the time more than one application is running on the computer, the controls of such an application also send messages to the operating system. As the operating system is constantly asked to perform these assignments, because there can be so many requests presented unpredictably, the operating system leaves it up to the controls to specify what they want, when they want it, and what behavior or result they expect. These scenarios work by the controls sending events.
Events in the .NET Framework are implements through the concepts of delegates and events as reviewed previously. The most common events have already been created for the objects of the .NET Framework controls so much that you will hardly need to define new events. Most of what you will do consists of implementing the desired behavior when a particular event fires. To start, you should know what events are available, when they work, how they work, and what they produce.
To process a message, it (the message) must provide at least two pieces of information: What caused the message and what type of message is it? Both values are passed as the arguments to the event. Since all controls used in the .NET Framework are based on the Object class, the first argument must be an Object type and represents the control that sent the message.
As mentioned already, each control sends its own messages when necessary. Based on this, some messages are unique to some controls according to their roles. Some other messages are common to various controls, as they tend to provide similar actions. To manage such various configurations, the .NET Framework considers the messages in two broad categories.
As it happens, in order to perform their intended action(s), some messages do not require much information. For example, suppose your heart sends a message to the arm and states, "Raise your hand". In this case, suppose everything is alright, the arm does not ask, "how do I raise my hand?". It simply does because it knows how to, without any assistance. This type of message would be sent without much detailed information.
In the .NET Framework, a message that does not need particular information is carried by a class named EventArgs. In the event implementation, an EventArgs argument is passed as the second parameter.
Consider another message where the arm carries some water and says to the mouth, "Swallow the following water". The mouth would need the water that needs to be swallowed. Therefore, the message must be accompanied by additional information. Consider one more message where the heart says to the tongue, "Taste the following food but do not swallow it." In order to process this message, the tongue would need the food and something to indicate that the food must not be swallowed. In this case, the message must be accompanied by detailed pieces of information.
When a message must carry additional information, the control that sent the message specifies that information by the name of the second argument. Because there are various types of messages like that, there are also different types of classes used to carry such messages. We will introduce each class when appropriate.
Although there are different means of implementing an event, there are two main ways you can initiate its coding. If the control has a default event and if you double-click it, the designer would initiate the default event and open the Code Editor. The cursor would be positioned in the body of the event, ready to receive your instructions.
As another technique, display the form and click either the body of the form or a control on it. Then, on the Properties window, click the Events button , and double-click the name of the event you want to use.
Another alternative you can use consists of displaying the form, right- clicking the form and clicking View Code. Then, in the Class Name combo box, select the name of the control:
In the Method Name combo box, select the event you want to implement:
While an application is opening on the screen or it needs to be shown, the operating system must display its controls. To do this, the controls colors and other visual aspects must be retrieved and restored. This is done by painting the control. If the form that hosts the controls was hidden somewhere such as behind another window or was minimized, when it comes up, the operating system needs to paint it (again).
When a control gets painted, it fires the Paint() event. The syntax of the Paint() event is:
Private Sub Control_Paint(ByVal sender As System.Object, _ ByVal e As System.Windows.Forms.PaintEventArgs) _ Handles MyBase.Paint End Sub
This event is carried by a PaintEventHandler delegate declared as follows:
Public Delegate Sub PaintEventHandler ( _ sender As Object, _ e As PaintEventArgs _ )
The PaintEventArgs parameter provides information about the area to be painted and the graphics object to paint.
When using an application, one of the actions a user can perform on a form or a control is to change its size, provided the object allows it. Also, some time to time, if possible, the user can minimize, maximize, or restore a window. Whenever any of these actions occur, the operating system must keep track of the location and size of a control. For example, if a previously minimized or maximized window is being restored, the operating system must remember where the object was previously positioned and what its dimensions were.
When the size of a control has been changed, it fires the Resize() event, which is a EventArgs type.
A keyboard is a hardware object attached to the computer. By default, it is used to enter recognizable symbols, letters, and other characters on a control. Each key on the keyboard displays a symbol, a letter, or a combination of those, to give an indication of what the key could be used for.
The user typically presses a key, which sends a signal to a program. The signal is analyzed to find its meaning. If the program or control that has focus is equipped to deal with the signal, it may produce the expected result. If the program or control cannot figure out what to do, it ignores the action.
Each key has a code that the operating system can recognize.
When a keyboard key is pressed, a message called KeyDown is sent. KeyDown is a KeyEventArgs type interpreted through the KeyEventHandler event whose syntax is:
Public Event KeyDown As KeyEventHandler
The KeyEventHandler event is carried by the KeyEventArgs class defined in the System.Windows.Forms namespace through the KeyEventHandler delegate:
Public Delegate Sub KeyEventHandler(sender As Object, e As KeyEventArgs)
When you initiate this event, its KeyEventArgs argument provides as much information as possible to implement an appropriate behavior.
As opposed to the key down message that is sent when a key is down, the KeyUp message is sent when the user releases the key. This event also is of type KeyEventArgs:
When the user presses a key, the KeyPress message is sent. Unlike the other two keyboard messages, the key pressed for this event should (must) be a character key. This event is handled by the KeyPressEventHandler event whose syntax is:
Public Event KeyPress As KeyPressEventHandler
The KeyPress event is carried by a KeyPressEventArgs class. The Handled property identifies whether this event was handled. The KeyChar property identifies the key that was pressed. It must be a letter or a recognizable symbol. Lowercase alphabetic characters, digits, and the lower base characters such as ; , " [ ] - = / are recognized as they are. For an uppercase letter or an upper base symbols, the user must press Shift + the key. The character would be identified as one entity. This means that the symbol % typed with Shift + 5 is considered as one character.
The mouse is another object that is attached to the computer allowing the user to interact with the machine. The mouse and the keyboard can each accomplish some tasks that are not normally available on the other or both can accomplish some tasks the same way.
The mouse is equipped with two, three, or more buttons. When a mouse has two buttons, one is usually located on the left and the other is located on the right. When a mouse has three buttons, one usually is in the middle of the other two. A mouse can also have a round object referred to as a wheel.
The mouse is used to select a point or position on the screen. Once the user has located an item, which could also be an empty space, a letter or a word, he or she would position the mouse pointer on it.
To actually use the mouse, the user would press either the left, the middle (if any), or the right button. If the user presses the left button once, this action is called Click. If the user presses the right mouse button, the action is referred to as Right-Click. If the user presses the left button twice and very fast, the action is called Double-Click.
If the mouse is equipped with a wheel, the user can position the mouse pointer somewhere on the screen and roll the wheel. This usually causes the document or page to scroll up or down, slow or fast, depending on how it was configured.
Before using a control using the mouse, the user must first position the mouse on it. When this happens, the control fires a MouseEnter event. Its syntax is:
Public Event MouseEnter As EventHandler
This event is carried by an EventArgs argument but does not provide much information, only to let you know that the mouse was positioned on a control.
Whenever the mouse is being moved on top of a control, a mouse event is sent. This event is called MouseMove and is of type MouseEventArgs. Its syntax is:
Public Event MouseMove As MouseEventHandler
To implement this event, a MouseEventArgs argument is passed to the MouseEventHandler event implementer:
Public Delegate Sub MouseEventHandler ( _ sender As Object, _ e As MouseEventArgs)
The MouseEventArgs argument provides the necessary information about the event such as what button was clicked, how many times the button was clicked, and the location of the mouse.
If the user positions the mouse on a control and hovers over it, a MouseHover event is fired:
Public Event MouseHover As EventHandler
This event is carried by an EventArgs argument that does not provide further information than the mouse is hovering over the control.
Imagine the user has located a position or an item on a document and presses one of the mouse buttons. While the button is pressed and is down, a button-down message is sent. This event is called MouseDown:
Public Event MouseDown As MouseEventHandler
The MouseDown event is of type MouseEventArgs. Like the other mouse move events, the MouseDown event is carried by a MouseEventArgs argument.
After pressing a mouse button, the user usually releases it. While the button is being released, a button-up message is sent and it depends on the button, left or right, that was down. The event produced is MouseUp:
Public Event MouseUp As MouseEventHandler
Like the MouseDown message, the MouseUp event is of type MouseEventArgs which is passed to the MouseEventHandler for processing.
When the user moves the mouse pointer away from a control, the control fires a MouseLeave event:
Public Event MouseLeave As EventHandler
To support drag n' drop operations, the .NET Framework provides various events through the Control class. The object from where the operation starts is referred to as the source. This object may or may not be from your application. For example, a user can start a dragging operation from a file utility (such as Windows Explorer). The object or document where the dragged operation must end is referred to as the target. Because you are creating an application where you want to allow the user to drop objects, the target is usually part of your application.
To start the dragging operation, the user clicks and holds the mouse on an object or text. Then the user starts moving the mouse. At this time, if the source object is from your application, the control fires a DragLeave event:
Public Event DragLeave As EventHandler
This event is of type EventArgs, which means it doesn't carry any information, just to let you know that a dragging operation has started.
The user drags an object from one location to another. Between the source and the target, the user may pass over another object but that is not the target. If this happens, the control that is being over passed fires a DragOver event:
Public Event DragOver As DragEventHandler
The DragOver event is handled by a class named DragEventAgs. Most of the time, you will not be concerned with this event because most drag n' drop operations involve a source and a target. For this reason, we will not review this class at this time.
At one time, the user will reach the target. That is, before dropping the item. At this time, the control over which the mouse is positioned fires the DragEnter event:
Public Event DragEnter As DragEventHandler
At this time, the user has not yet decided to drop the object or not. This is important because at this time, you can still make some decisions, such as identifying the type of item the user is carrying, whether you want to allow this operation or not, etc.
The DragEnter event is handled by the DragEventArgs class. One of the properties of this class is named Effect. This property is of type DragDropEffects, which is an enumeration.
Probably the most important piece of information you want to know is what the user is carrying. For example, a user can drag text, a picture, or a document, etc. To assist you with identifying what the mouse is holding, the DragEventArgs class is equipped with the Data property, which is of type IDataObject.
Once the user has reached the target and still wants to complete the operation, he or she must release the mouse. At this time, the object on which the mouse is positioned fires the DragDrop event:
Public Event DragDrop As DragEventHandler
The DragDrop event is handled by the DragEventArgs class.
It is possible, but unlikely, that none of the available events featured in the controls of the .NET Framework suits your scenario. If this happens, you can implement your own event. To do this, you should first consult the Win32 documentation to identify the type of message you want to send.
There are two main techniques you can use to create or send a message that is not available in a control. You may also want to provide your own implementation of a message.
In order to send a customized version of a Windows message from your control, you must first be familiar with the message. A message in the .NET Framework is based on the Message structure. One of the properties of this structure is Msg. This property holds a constant integer that is the message to send. The constant properties of messages are defined in the Win32 library. To send a message, you can declare a variable of type Message and define it. Once the variable is ready, you can pass it to the DefWndProc() method. Its syntax is:
Protected Overridable Sub DefWndProc(ByRef m As Message)
To know the various messages available, you can consult the Win32 documentation but you need a way to get the constant value of that message. Imagine you want to send a message to close a form when the user clicks a certain button named Button1. If you have Microsoft Visual Studio (any version) installed in your computer, you can open the WINUSER.H file. In this file, the WM_CLOSE message that carries a close action is defined with the hexadecimal constant 0x0010
You can then define a constant integer in your code and initialize it with this same value.
To process a Windows message that is not available for a control you want to use in your application, you can implement its WndProc() method. Its syntax is:
Protected Overridable Sub WndProc(ByRef m As Message)
In order to use this method, you must override it in your own class. Once again, you must know the message you want to send. This can be done by consulting the Win32 documentation.