Event Driven Programming

Keywords: event driven programming features, handing microsoft events

P1 Describe the key features of event driven programming

Event handlers – The GUI is formed of a great deal of built in things such as text boxes, tool icons menus etc. When the user clicks on a mouse or presses a key on the keyboard they trigger these GUI features. This sort of interaction is called events. Windows operating systems provide the event driven program with these event triggers.

The code is written so that it reacts to every event that arise through user interaction.

Events are the activities which are carried out by the user when the program is being used. When the user clicks on any object then the Click event is executed. If the user repositions the mouse then the mouse move event occurs. By the similar method a program can produce Key down event, Key up event, mouse double click event. The event is perceived by a form or control. Code is initiated by a program in reaction to an event. All forms and controls in VB have a set of events already in place.

If one of these events takes place, VB brings up the code in the related event process.

Despite the fact that predefined collection of events are detected without human intervention by objects in VBA, it still up to the programmer to decide if and how they react to a specific event. Event procedures are written for events in order to make a control respond to an event. Different objects can trigger different event processes when an event happens, although a lot of objects recognise the same event. For instance,if a user clicks
a userform, the Userform_Click event process takes place; if a user clicks a command button named CommandButton1, the CommandButton1_Click event procedure is triggered. Usually there are two different types of events. There are the events which are triggered by user interaction (clicking on a mouse, pressing a key on the keyboard) and there are System initiated events which are events produced to respond to a user action (scrolling text, highlight a button). Both of these events have to be dealt with in a UI. It is also possible that a user event triggers a system initiated event. What happens in a classic event driven application is the user opens the program and triggers an event by clicking on a button or pressing a key on the keyboard or the code in the program can trigger an event for example loading a form from the Load event procedure. The event is received by the program. If there is an event procedure in place for that particular event then the task is performed. The program then waits for another event to happen.
 An event handler deals with these events. All events are parts of data from the main configuration usually the GUI toolkit. Event handlers are very important elements of event driven programming. The events are generated by the structure found on understanding lower-level interactions, which could be lower-level events themselves. For instance, by moving the mouse the program takes this to be a menu selection and timers running out. The events primarily are initiated from actions on the operating system level, for example, interrupts produced by hardware devices, software interrupt instructions, or state changes in polling. In these circumstances interrupt handlers and signal handlers relate to event handlers. An event loop is where the program takes delivery of an event, deals with the event and then waits for another event and then executes a trigger function to deal with it. Trigger functions are written to correspond to the necessary actions. The algorithm which has been programmed has to make sure that triggers which have been made available are performed as soon as they are required which as a result presents a software concept that imitates an interrupt driven structure. The event loop normally doesn’t stop until the user closes the program. When it receives the event it initiates the suitable event handler.

This will ultimately be built-in to your application as a window. You can insert controls to this which might include a text box, check box command buttons etc

Every event is examined by a dispatcher so that it can decide what sort of event it is, and the event is then sent by the dispatcher to the associated handler so that the particular event can be processed. The dispatcher has to deal with a flow of input events. Once an event is transmitted it has to be looped back so that it can deal with the next event, this is done via the event loop. Several programs particularly those which control hardware could be endless and consequently would have to designate a special event to end the event stream (an end of file marker or pressing the escape key). For this to happen there has to be a quit facility in the dispatcher logic, so that an event looped can be stopped when the special event is found.

In some circumstances, the dispatcher could decide that there is no suitable handler for the event. When this happens, the event could be ignored or an exception could be initiated.

Events that don’t have handlers would be ignored by A GUI program because GUI programs are only concerned about particular types of events. For example although it might act on a mouse click it may not act on mouse movement. In the majority of other programs if an event is not recognised then it is regarded as an error which causes an exception to be initiated.

There is an event queue which is used for storing events when the dispatchers or handlers can’t deal with the events as quickly as they come in. The events queue is brought in to the events stream where the stream can be temporarily held. When an event comes in it is put to the back of the queue and the dispatcher deals with the events at the front of the queue as quick as possible.

Most GUI programs have an event queue. It might take longer to process larger events like mouse clicks, so at the same time this event is being dealt with other events such as mouse movement might build up in the queue however as soon as the dispatcher is ready it can quickly get rid of the meaningless mouse movement events so that the event queue is cleared out quickly.

P2 What is most noticeable in event driven programming is the flexibility that it provides, and the way in which it makes an effort to be as modeless as much as it can.. Graphical user interface applications are usually programmed in an event driven way. Event Driven Programming is relatively easy to do especially in Visual Basic because they have incorporated some revolutionary tools to help us along. Drag and drop design tools, property sheets, plus click and code aids helps make EDP less of a burden. Because of the flexibility offered with Event driven programming, it is an extremely popular method, especially for creating GUI programs. With Visual Basic EDP is simple because we are given various design tools to work with in order to produce user interface components (windows and dialog boxes) On top of this we are also provided with a complete suite of Windows interface components (including command buttons, text fields, list boxes, pictures, drop-down menus and file system controls) which can be created at the touch of a button without the need to write any code.  The forms engine for producing the interface applies technology obtained from Cooper Software. We can then add functionality to these interface components, which react to events. By programming in EDP we are also able to adapt procedures quickly and respond to faults. Event Driven programs are used in in Automatic Teller Machines (ATM), Point of Sale (POS) systems, certain types of smart cards, Internet kiosks and handheld devices

M1 Windows Operating systems are event driven programs in two ways. In one way it is similar to EDP because it uses interrupt handlers which are used as direct event handlers for hardware events, but replaces the job of the dispatcher with CPU hardware. In Windows Operating systems, data and software interrupts are transferred to user processes which usually are written as event handlers themselves, so in short the Operating system perform as dispatchers. Microsoft Windows take action when initiated by messages which are sent to the main application thread. So that the program can receive these messages the program continuously calls the GetMessage function which is found in the event loop. This means that Microsoft Windows is event based.

Once a little elective processing has been carried out, the DispatchMessage() is summoned to dispatch the message to the appropriate handler which is called the WindowProc.

In Microsoft Windows a message loop is created by user-interactive procedures to react to events, the message is connected to the event and is forced on the OS. The event doesn’t just have to be user interaction but can also be things like network traffic, system processing and timer activity.

Windows operating systems also have an event queue (or message queue as it is in Windows) which is where the messages are kept. Messages are dispatched to a particular job among a cluster of collaborative jobs. Messages are received by a window handle object via a WinProc, all of which correspond to an independent task in that system. In order for the next message to be dispatched a task has to finish its job as quickly as possible.

D1 Event driven Programs are able to set off warnings, based on business policies. With the network and applications repeatedly collecting and sharing observed events, organizations get direct access to “in-context” data on the root of the problem and the consequences if it was to happen. This facilitates combined decision-making which gives an organisation the power to avoid unfavourable situations and, finally, to enhance competiveness in numerous aspects. For example, if a sensor discovers that part of the equipment in an isolated plant has broke down. This data is linked to a customer contract which has a service-level agreement with it. A warning corresponding to the equipment which has broke down and its effect on the customer contract is dispatched to the appropriate personnel throughout the business —business analysts, plant operations, and production control personnel. At the same time, a meeting can be set up with these people so that they can consider the effect of the fault, when it will be fixed, and how business procedures should be altered so that they are better prepare if it was to happen again in the future.

Events don’t just have to be triggered by user interaction but can also be triggered by other applications (application events) or by system events such as alarms or warnings.

Copied

Modern business processes often require the blending of automation into the work environment through the invocation of behind-the-scenes functions and procedures. Behind-the-scenes tasks can include the automatic production of output such as an invoice that prints automatically when an order is processed, a Web site that is automatically updated with current data, or an automatic e-mail with fresh report output when a transaction is completed.

A solution often adopted is to write the application in the style of an event driven system. That is, something happening and to which a task should respond, is modelled as an event. The event is put together by a central thread of control, with the event and thread of execution being handed over to the appropriate task. It is now the tasks job to deal with that event and subsequently return the thread of execution back to the executive or dispatcher.

In an event driven system, a task, when allowed to run, must return control when it no longer requires it or when it can not precede further. That is, the task cannot perform an operation which would cause execution to block within that task. If the task was half way through an operation and was waiting on more data, it would need to remember where it was and return. When the data it was waiting on arrived it would then continue from where it had previously stopped. The thread of execution must be given back to the dispatcher in order to allow other tasks to run and deal with their own events. The tasks therefore must cooperate with each other to ensure that all are able to get through their respective jobs.

At a lower level, an event driven system can also be viewed as being a form of simulation system. In simulation systems, there is a list of jobs to be performed. The central executive or dispatcher retrieves the first job from the list and executes the code associated with the job. The code must eventually return so that succeeding jobs in the list can be executed. If it was not possible to finish an operation, the code for that job would add a new job to the end of the list of jobs such that the operation could be completed at a later time.

The main difference with an event driven system is that the central executive or dispatcher must be aware of a number of primary event sources. When the dispatcher goes to retrieve the next job to execute, it must also check the event sources and if an event is waiting, create a job for the delivery of the event to the appropriate task.

In a simulation system, when there are no more jobs to execute the program would terminate. For an event driven system, while ever any of the primary event sources are active and tasks are interested in events from those sources, the process will continue to execute. This means that if there were no jobs to execute in the list of jobs, the process would block and wait for an event to arrive. As the process itself is blocked, those events will of necessity be the result of some stimulus from the operating system. For example, a timer or alarm expiring, a signal being directed at the process, or data being ready for the process to read.

But first, what are the business opportunities enabled by EDA and where do they exist? Consider the airline industry as a good example. Airline operators monitor weather sources, customer reservations, and air traffic control in real-time to manage their daily flight schedules. Their event-driven systems provide pricing adjustments and re-scheduling based on the real-time, complex analysis of those event streams in order to maximise their profitability and operational efficiency. This is a classic EDA benefit: optimised business operations with real-time information and increased operating margins

Almost every company has a daily operational aspect that can benefit from an EDA solution. A poultry processor in the midwestern United States provides an example from the manufacturing sector. This processor utilises distributed cooling equipment throughout its plant to keep the temperature below 50 degrees as per U.S. Department of Agriculture regulations. Equipment malfunctions are very costly to the business – all products within the processing area must be scrapped if the temperature rises above 50 degrees. The coolant substance is also a potentially harmful chemical, thus any leaks requires a plant evacuation. For all these reasons, the cooling equipment must be closely monitored and maintained, 24×7.
This monitoring and maintenance is typically done on a regularly scheduled basis around the clock. That requires significant resources however, so the company implemented an EDA solution that included physical sensors to capture equipment diagnostic information across the plant. The diagnostic information is now automatically captured and analysed every few minutes, making it easy to identify pieces that are potential candidates for failure. Not only can they fix the equipment before it breaks, but they have also alleviated the need for round the clock maintenance staff in favour of a more ‘management-by-exception’ approach.

Greater efficiency and lower costs are not the only benefits. Companies are also using EDA solutions to generate a competitive advantage in their industries by providing unique and differentiated real-time services.

EDA solutions provide excellent opportunities for companies to become a leader in their industry, through better management of their daily operations and the unique services they can provide to their customers. These solutions take advantage of existing IT investments, creating more value through the analysis and processing of events that already exist within most applications and IT systems. As EDA solutions have evolved into more standards-based and open systems, the speed and cost of implementation have also greatly decreased, making now an attractive time to invest.