As opposed to being described, an object can perform actions. For example, a Person object can sing. A Car object can move. An Insect object can crawl. A Basket object can hold some clothes. Here are examples of actions:
Notice that some objects can perform similar types of actions. For example all objects of this table can move. Some objects can perform actions that some others can't. For example, from the objects in the above table, a person and a dog can eat. In the programming world, an action that an object can perform is called a method. Like a property, a method must have a name. On the above table, notice that the name of a method usually (if not always) resembles a verb. Examples are Bark, Eat, or Drink. To make a distinction between a property and a method, in these lessons, we will always follow the name of a method with empty parentheses. Examples are Move() or Bark(). Like a property, the name of a method is always in one word. Examples are Walk() or Crawl(). If the name is a combination of words, each part starts in uppercase. Examples would be TalkAloud(), SmellFood(), EatGrass(), or ProtectFromRain(). Because a method is performed, it cannot be represented in a window such as the Properties window. Eventually, we will know how to identify and use the methods of an object. Using a method is referred to as calling it. When a method can produce a result, it can be assigned to a property. To call a method, if it produces a result that can be applied to a property, if you are working in Microsoft Access, in the Properties window, locate the property that will use the result of the method. In the property value section, type the assignment operator "=", followed by the name of the object that owns the method, followed by a period operator, followed by the name of the method and followed by parentheses. In future lessons, we will see that there can be other issues involved with calling a method. To programmatically call a method, type the name of the object that owns the method, followed by a period operator, and followed by the name of the method.
A typical application is made of various objects that a person uses to interact with the computer. To make this interaction possible without confusion, each object creates its own messages and sends them to the operating system. The messages are as varied as possible, so are the objects of an application. To reduce any type of confusion, each message must carry three to four pieces of information: the name of the object that composed the message, the type of message that must be dealt with, additional information provided by the object that sent the message. Because the operating system cannot decide what type of action a particular object needs to perform at a particular time, each object is responsible to create its own messages. The first piece of information that an object must provide is its name. The reason is that there can be so many objects that are part of an application and there can be many applications opened at the same time. The second piece of information that a message must carry is its type. There are many types of messages that a control can compose. Many controls can also send the same types of messages. The operating system is already aware of the various types of messages that are available and, most of the time, it knows the types of messages that a particular object can control, but the operating system cannot decide what type of message a control wants to compose at one particular moment. The types of messages are mostly known with particular names. In the operating system, the names of messages start with WM_. If you log to the MSDN web site and do a search on words that start with WM_, you would find out that there are many messages available but you will not need to memorize their names or to be aware of all of them. In fact, there are many messages you will hardly use. After a control has composed a message, it must send it. The action of composing and sending a message is called an event. The action of actually sending a message is referred to as firing an event. To make it easy to identify an event, each event has a simplified name. When an object fires an event, the name of the event is appended to the name of the object. To distinguish the name of the object and the name of the event, there is an underscore between them. Examples are MainForm_Load or Customers_Dirty. As you will find out, the names of some events are made of more than one word. Examples are AfterUpdate or BeforeInsert. In this case, the name of the object and the name of the event are still added with an underscore between them. Examples are MainForm_AfterUpdate or Customers_BeforeInsert.
After composing a message and firing its event, when the operating system receives it, in order to perform the necessary action, in some cases, it (the operating system) may need additional information that the object must provide. The additional information is also referred to as parameter. The additional information that an object must provide is typed in the parentheses of the event. Normally, the operating system is aware of the type of additional information that the object must provide. If the object doesn't provide this information, the operating system would use some default value(s). Because the type of additional information of an event is already decided, when you generate an event, Microsoft Visual Basic includes this information in the parentheses of the event. If the message doesn't require additional information, its parentheses are left empty. If it may need parameters, they are automatically included in its parentheses. Because the structure of messages can be difficult to cope with, Microsoft Visual Basic has a simplified mechanism to help you code an event. Since an event is treated as a private matter, its code starts with the Private keyword. An event is treated as an action, like the methods we reviewed earlier. For this reason, it is created as a sub procedure and it must use the Sub keyword. After the Private Sub expression, follow the combination of the name of the object that is firing the event, the underscore, and the name of the event, and its parentheses with optional parameters depending on the event. There are various ways you can initiate an event on an object of your database. If you are working in Microsoft Access and if you open a form or a report, you should access its Properties window in Design View. If the form or report "carries" the control whose event you want to program, you should also first open the form or report in Design View.
Sometimes you or Microsoft Visual Basic will have inserted an event that you did not want or that you do not want to program. If this happens, simply ignore the event: you do not have to delete it because if an event has been initiated but no code was written for it, the application will ignore it and use a default behavior.
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|