Release 10.1A: OpenEdge Development:
Progress 4GL Handbook

> ## Contrasting procedural and event-driven programs

> Understanding the difference between procedural and event-driven programs is one of the most important requirements of learning how to write OpenEdge applications. The program you have written so far is a simple but good example of a procedural program. It executes basically from the top down. When it comes to a statement to `RUN` another procedure, such as the `calcDays` internal procedure, then it initiates that procedure, passes parameters into it, and when it gets to the end, returns any output parameters, and that’s the end of it. There’s no code placed off to the side for events initiated by the user. The programmer determines the procedure flow. A program doesn’t prompt the user for input until it’s ready to. The user has little ability to move around in the interface flexibly. This is typical of a character interface application. The simple diagram in Figure 5–2 illustrates top-down or hierarchy programming.

> Figure 5–2: Procedural top-down application flow

> When the procedure `mainproc.p` runs `a.p`, and then `a.p` runs `a1.p`, then `mainproc.p`, `a.p`, and `a1.p` are in memory. When`a1.p` returns, its context is removed and it goes out of scope. When `a.p` returns, its context is deleted. And only then can the code run `b.p`, which might run `b1.p`. The thread of execution goes right up and down through this hierarchy of called procedures.

> By contrast, your sample procedure from this chapter is a simple but very good example of an event-driven procedure, as illustrated in Figure 5–3. Most of the code the interpreter encounters as it initializes the procedure doesn’t actually get executed. It just sets up bodies of code to run when the user requests it.

> Figure 5–3: Event-driven application flow

Copyright © 2005 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095