Emma Christian
Event Driven Programming
Assignment 1 – Unit 14
Emma Christian14th - 20th September
Page Two: Explain and Illustrate Key Features of Event Driven Programming
Page Three: How operating system can be viewed as an even driven application
Page Four: Suitability of event driven programs for non graphical application
Books/Ebooks Used
Programming In Visual Basic 6.0 - Julia Bradley
Visual Basic For Windows - Harold Davis
Event Driven Programming PDF - Stephen Ferg
Windows Programming – WikiBooks
Wiki How - A few different people
Page 1
Emma Christian
Explain and Illustrate Key Features of Event Driven Programming
Event driven is a language that is based on the events that happen during the
execution of a program. These events are controlled by Event handlers, Trigger
functions and event loops. This basically means that nothing will happen unless an
event or series of them are triggered.
In Event driven models the programs are not procedural any longer. One of the main
features of Event Driven Programming is that it creates a user friendly environment,
because when the user takes an action, this action triggers a chain of events which
cause the program to do what the user wants (within its programming, of course).
The program waits for the event to occur, and as soon as that happens the even
handlers will delegate the event and take the most appropriate action.
Unlike some other types the program flow is not dependant on the program, and
does not follow sequential logic. Event Driven is run by several different procedures,
all of which are designed to react to something the user does, these reactions can be
set on a timer, or on placement, or can even be delayed until two things happen
simultaneously. This allows everything to be more dynamic, and 'intelligent'.
I suppose it would not be that much of a big leap in logic to believe that this would be
perfect for robots, as this could make them react to something that a real person
does, or another robot. For example if you wanted to talk to one, the user asking
them a specific question could trigger a reaction? Or perhaps poking them in the eye
could make them tell you not to do that, or cause them to blink? This would actually
also fit into section three, as robots would look kind of silly with Graphical interfaces,
and therefore would probably be of the non graphically orientated type (also so that
they would be more human like, most humans have a healthy dose of narcissism
after all).
Anyway, this all means that the user has an incredibly specific control over the
application, even if they just click a mouse button in the right place, this could trigger
reactions to open a new page, or duplicated data. I guess this is like if you flung a
ball out a window, and a dog grabbed it, and ran into the road, was then caught by
some dog catchers, and became the president of China's dog... (For example) Then
the throwing the ball out the window would be the trigger function and the event
handlers would be the dog handlers.
Despite the fact that most applications rely on user input (to know what to do next), it
would also be possible for code to run without an even triggering it. This would work
in VB as it takes care of the details of checking for event invisibly, and then calls the
user on the procedures when needed.
Visual basic is a Integrated development environment (IDE) because it can edit,
compile, automate and debug code. The virtual environment that a ID provides is one
you can use as a playground of sorts to develop software, and program computers.
They are generally event or object orientated, although we shall only be focusing on
the Even Driven side of things. The Environment not only supports those things, but
also are made to make programmers as productive as possible (in a short number of
mouse clicks or keyboard Klunks) This is done by when the programmer writes
something like 'It' then a list will trigger than will give them a drop down list where
they will be able to navigate it incredibly quickly and finish off the word and if it's not
the end of a section then they can do it again. 'Items.A' - where they can then select
add and then jump to the next line. They have successful reduced 11-13 keyboard
Klunks to only 3-4! This is obviously very useful. As to businesses Keyboard Klunks
cost time, and time costs money. This then will cost the worker money when they
don’t get a Christmas bonus for being too slow. This is also done so that there shall
be less mode switching. Note that the higher productivity will only come with time and
practice, since having to read a manual or guess shortcuts will only add time. Visual
IDEs even give building block type programming shortcuts.
Page 2
Emma Christian
How operating system can be viewed as an even driven application
Operating systems for personal computers have always been event driven. If you
look back to MSDOS it had to respond to interrupts from such things as a mouse to
the processor.
t responds to a given event, you click on something, and the computer does what it is
told, after the event of said clicking. For example you want to save a file, you will click
the save button and that causes the machine to write the file to disk. Another
example would be if you press exit the machine will take the command and start the
event of shutting down the computer. Every single operation is preceded in somehow
by an event or action. Modern Operating systems have to be even more event driven
than the older ones, as the have to deal with all the events the old systems had to
deal with and more. For example the act of plugging a memory stick into a USB
causes an interface to pop up, and in some cases the folder which is contained in it.
The computer has to assign this a high priority (with your permission, memory sticks
are suspicious, you know) and then make sure it deals with this straight away,
instead of pushing it behind a program like World Of Warcraft and NEVER emerging.
Besides, people panic easily, and may think that their memory stick with its precious
work is gone, if it takes longer than 10 seconds to load up. This is the same with
microphones and headphones as nowadays the headphones have to be confirmed
as headphones on a little graphical interface before they are connected, because of
all the new things that they just might be instead.
Priority scheduling is now on most computers and is a perfect example, especially of
the pre-emptive type. The Operating System has the power to temporarily suspend a
current task to instead focus on a higher priority even and then unsuspended the
suspended task. This priority scheduling (of handling processes and I/O and CPU
scheduling) is done through an event based scheduling hierarchy.
Preemptive multitasking is when a Operating System uses a method to determine
how long one task gets to run before handing the reins over to another task to use.
Some determinations are because the task is taking too long (called time sharing),
not being able to finish without the other one finishing first, and priority problems.
Page 3
Emma Christian
Suitability of event driven programs for non graphical application
If you think about it, ATMs are programmed, and they don't have to be graphical, I
mean it can never really know when someone is about to use it and at exactly the
same time a message from the bank occurs! But it can take these events and
support both of them at the same time... Imagine how worried/confused a user would
be if the ATM locked onto another task just as they had given it their card? Or how
much of a waste of time it would be if the bank had to wait for people to stop using it
to do something to the ATM?
If you think about the fact that event driven programs react to external stimuli then
suddenly thousands of things become event driven, and some of them are
programmed! For example some of the newer cars have small 'computers' that are
able to monitor the condition of the car and react to said conditions and events. For
example if the breaks stop working or the airbags are disconnected. ED can be good
for any type of process.
An event driven application does not have to be completely operated and babysat by
a user, nor does it have to have an external UI. It could for example it could sit and
listen for pings, and then trigger an event of another program. Or it could collect data
from different parts of the country just by listening to connections from external
sources. Another example goes back to the previous topic. The kernel of the OS is
event driven, and not necessarily a graphical interface, and does not need or depend
on a graphical environment. It could be controlled through a series of buttons to get
the same job done, or something from an external source.
Another thing that I can think of would be a program that exists solely to watch for
changes in the computer, and then sends the results to another program who makes
them all pretty to tell the user. The actual program itself has no graphical interface,
and does not need one, as the security system does. The level we are talking about
also matters, you see. Assisting programs do not really need GIs nor would a
background program, or a worm/virus. You never saw one of them with a graphical
interface, now did you? Also you can certainly argue that some viruses are not only
opportunistic, but are also event driven, because they are affected and adapt to the
system around them. They can simply hijack another program to use theirs. Although
that would be more Trojan and less worm... Ah well.
Non-graphical applications would need to use non-user initiated events at certain
times too, such as times. I really do think that a good measure of judgement and
sense is to be used when deciding to make it event driven, or something else. There
are a lot of times when they would be suitable, but they are certainly not required in
all applications.. The purpose would certainly have to be considered. For example
when an application only has one thing going on, then it has no need to be put into a
hierarchy, or ran alongside something else, or trigger a chain of events.
Page 4