|
Nathan hit the point! What is event driven programming? and John E offered one half of the answer. Its a programming style as procedurale is another. Understanding the diffrence between these too (lets concentrate on these too only, thow there are others), it doesn't help to say : there are events in procedurale programming too, or saying there is procedurale code in event driven programming too. The point of importance is: what dominates the design of the software?
Having a look to a typical subfile programm, the procedurale logic of the programm controlls the flow of the application and guides the user through a sequence of screens. The user could influence the movies a little bit, but with most of these programms, the programm would have to be altered to make the final confirmation screen to the first screen of the edit record part of the application. For these kind of programms RPG and COBOL are both a good choice.
No let's have a look to an application doing this under the controll of a Windows system (might be Microsoft Windows, or x Windows, or Swing or SWT). The application would send some data to some Windows, there would be some components with enabled events, maybe a button. To each of these possible events an EventHandler is registered to the Windows Runtime. If one of these events is fired (the User pressed a Button, for instance) the Windows runtime opens up a new Thread (not my programm!!!) and the registered EventHandler Method is called (that's the call back pattern).
Comparing the procedurale approach (the subfile programm) with the event driven (the programm under the controll of the Windows System), the first diffrence is a technical one: with the second approach all EventHandler methods are running in a Multithreaded Environment (you can't avoid this, it's the Windows runtime, doing this). The Subfile Programm is 5250 and won't run in a Job allowing Multithreading and so none of these programms is prepared for Multi Threading (that's no problem, but you would have to change your coding and coding style to port these programms to a Multithreaded Environment).
The second diffrence is a design issue: with the procedurale approach (the subfile programm) you could controll the application flow to present screens in a predefined sequence and for 5250 it's further restricted: only the last screen could have active Function Keys (here we have an Event in a procedurale design!!!). Most 5250 applications follow the procedurale design paradigm, controlling the application flow dominates the programm logic. Following the event driven paradigm, you would not even try to controll the flow of the application, instead of this your application will react to Events, based on the current state of the application and each of the Events alters the state of the application. These applications are dominated by holding the complete state of a process, waiting for Events, not knowing which Event might occur next, having multiple active screens with active Events out at the same time, reacting to Events altering the state happening maybe simultaneously -
and for this I would not even think about using RPG.
Dieter
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
