OpenEdge Development: Progress 4GL Handbook

Introducing the Progress 4GL

The Progress® 4GL is a high-level procedural programming language, developed to enable you to build almost all aspects of an enterprise business application, from the user interface to the database access and business logic. Over its twenty-year life span, the Progress 4GL has grown into a versatile and extraordinarily powerful tool, not only allowing you to use it to program applications, but to build many of the tools that you use to help create and support those applications.

This chapter provides an introduction to the Progress 4GL. It includes the following sections:

Getting started with the 4GL—the Progress snowplow
In the beginning…FOR EACH CUSTOMER
Basic characteristics of the Progress 4GL
Saving your test procedure

The Progress programming language is a fourth-generation language (4GL) because it has powerful statements and keywords that are specialized for building business applications. Single programming statements in the 4GL can do the work of dozens or possibly hundreds of lines of code in a standard 3GL, such as Visual Basic, Java, or C++. A single 4GL statement can bring data all the way from the application database to the user interface, or return a user’s changes back to the database. Other statements let you program with great precision, even down to the level of extracting individual bits from a data stream. This flexibility is what gives the Progress 4GL its great power as a development language. Most of the development tools you use to develop OpenEdge™ applications are themselves written in the 4GL.

In its first releases, in the early 1980s, the Progress 4GL allowed developers to build character interface applications that ran on a wide variety of hardware platforms, including many varieties of UNIX, DOS, and some other operating systems no longer in use. Early Progress applications were, from the very first, fully portable between platforms so that a developer could simply move application programs from one type of machine or one type of display terminal to another with confidence that they would work correctly everywhere.

With the increasing presence of Microsoft Windows as a platform for graphical interfaces, the 4GL evolved to support those interfaces, with all their various visual controls, as well as the event-driven programming constructs needed for a menu-and-mouse-driven application. Today the 4GL continues to grow, with newer extensions to provide more and more dynamic definition of application components, as well as access to open technologies such as HTML and XML, and a host of other constructs to support an open application development and deployment environment.

And all the while, Progress 4GL-based applications can be brought from one release to the next largely without change. Progress provides a degree of compatibility and upward migration from one release to the next unmatched (unattempted, really) by any other high-level programming language.

About the sample database

This book uses one of the standard OpenEdge sample databases for its examples, the Sports2000 database. This is a simplified example of a database that might be used in a typical order entry application, with customers, orders, order lines, and other information for keeping track of customers and their orders. Some of the same example procedures and windows you will build are used and extended throughout the book as you are introduced to new programming concepts, but you will not be building a complete sample application. This is largely because, in the course of introducing so many separate language constructs and programming techniques, the book gives you more of a one-of-each experience that would not be typical of a standardized application. Once you’ve worked through the book, though, you will be able to use what you learn to build many kinds of comprehensive applications.

Getting started with the 4GL—the Progress snowplow

Have you ever learned to downhill ski?

The first thing the ski instructors teach you is how to do the snowplow by moving the tips of your skis close together so you can control your descent down the hill as you learn to keep your balance. (If you were really young when you learned, they probably talked to you about making a piece of pie, right?)

Then what is the second thing they teach you, after you can get down the hill safely? It is never to snowplow again, because you have to learn to ski with your skis parallel to ski well. The snowplow is just to get you started, to help you survive your first runs down the hill until you are ready to do things the right way.

This book uses a similar technique to show you how to use the Progress 4GL. The language and the tools that support it have evolved to the point where much of the work of building an application has been taken over by the development tools themselves. Because of this, the nature of the 4GL procedures you typically write has changed to take advantage of what the tools do for you, as well as to use the enhancements to the language that have appeared with each new release. So while it is important to learn the basics of how the language works and everything that you can do with it, once you understand these things you will want to let the OpenEdge tools generate much of your 4GL code for you, including many of the visual elements of the application and even some standard business logic.

One of the major development tools is the OpenEdge AppBuilder, a graphical design tool you can use both to build structured procedures for your 4GL code and to design and build windows, browses (or grids), menus, and the other parts of a GUI application. The AppBuilder is a code generator. When you lay out a window in the AppBuilder, it generates the 4GL code to define the window and all the controls that are in it. The AppBuilder can do a great deal more, defining not just graphical elements, but also the database access 4GL code needed to retrieve data from one or more database tables, display it, and update it, all without you having to write any code yourself at all.

Because the AppBuilder can generate this code for you, you won’t have to write it yourself in the applications you develop. But you need to be aware of what that code looks like and what it does for you, so that you can understand and appreciate how the code you do write fills in the blanks where the tools don’t do everything you need.

In "Examining the Code the AppBuilder Generates," you’ll look at some of that AppBuilder-generated code as you learn how to define a graphical application. After that chapter, you won’t have reason to write that kind of code very often at all. This book shows you the basics of what the AppBuilder does and how to use it. Other manuals in the OpenEdge documentation set provide details on how to use the AppBuilder and related tools that are part of the OpenEdge Application Development Environment (ADE).

Another major tool is the Progress Dynamics™ development framework. Progress Dynamics is a comprehensive set of tools and supporting code to help you develop distributed, largely dynamic business applications. Distributed means that your applications can run worldwide, with a database server on one machine accessed by users working on many separate PCs or other workstations. They interact with the interface part of your application and exchange data with the server machine when it’s needed. Dynamic means that much of your application definition isn’t in procedure code at all. Rather, it is stored in a repository database that describes the whole user interface and even much of the logic of your application in abstract terms that can be presented to the user in different ways (for example as a Windows-style GUI interface or a Web-browser HTML interface) without any code changes to accomplish this.

Building a distributed application by yourself, let alone a dynamic distributed application, would definitely be the programming equivalent of a double-black-diamond ski run—a very advanced undertaking, not for the inexperienced or the faint of heart. But Progress Dynamics handles most of the work for you, generating application components that handle the large majority of the tasks your application requires. You are left to write 4GL procedures to define the specific business logic for your application, along with other customizations and extensions that you need. Because the framework does so much for you, much of the code you write in a snowplow application, such as you will create first in this chapter, won’t be the kind of code you write in a real application. For that reason, the first chapters of this book introduce some basic language concepts and constructs. Later chapters quickly move on to teach you to build code in the context of a real application.

There are several other books that teach you everything you need to know about the very powerful Progress Dynamics development environment. This book just provides you with enough guidance to help you build the things you need.

You can use what you learn from this book to build OpenEdge applications in a variety of ways, including using some of the newer constructs to extend and enhance an existing application written in an earlier version of the 4GL.

In the beginning…FOR EACH CUSTOMER

There’s a prototypical Progress 4GL procedure often used as an example, one that couldn’t be simpler, but that shows a lot about the power of the language. It’s appeared on coffee mugs and tee shirts for two decades. Here it is:

FOR EACH Customer:     DISPLAY Customer. END.

You can’t get much simpler than that, but it would take hours to explain in detail everything that this little procedure does for you. To summarize:

Customer is the name of a table in the Sports2000 sample database that you’ll connect to in a moment. The FOR EACH statement starts a block of code that opens a query on that database table and returns each record in the table, one at a time, in each iteration of the block.
Each Customer record is displayed on the screen in turn. The code takes formatting and label information from the database schema definition and uses it to create a default display format for all the fields in the table. DISPLAY Customer means display all the fields in the table.
As each record is displayed, the display moves down a row to display the next Customer. The effect is more like what you would see in a report rather than a browse or other grid control.
The block of code—everything from the FOR EACH statement through the END statement—iterates once for each Customer record (hence the syntax FOR EACH). All the code in between (in this case just a DISPLAY statement) is executed for each customer retrieved.
When the display gets to the bottom of the available display area, it automatically pauses, with a message prompting you to press the space bar to see the next set of rows.
When you press the space bar, the display clears and a new set of rows appears.
When Progress detects the end of the record set (all the Customer records in this case), it terminates the procedure with the message “Procedure complete. Press space bar to continue.”
If you get tired of looking at Customers (there are several hundred in the table), you can press the ESCAPE key to terminate the procedure.

Starting your OpenEdge session

So where do you enter this little piece of code? First, you need to start a OpenEdge session, create and connect to a copy of the sample database the example uses, and then bring up the Procedure Editor.

To start your OpenEdge session:

From the Windows desktop Start menu, select the OpenEdge environment, using whatever name you gave to it when you installed it, and under that menu item, select the Desktop option. For example, select Start OpenEdge Desktop.
The Application Development Environment (ADE) Desktop window appears:



From here you can access all the basic OpenEdge development tools.
Choose the first icon, which looks like a book .
The OpenEdge Data Dictionary Startup dialog box opens. The Data Dictionary is where you define and manage all the tables and fields in your application database. To get you started, you can create your own copy of the Sports2000 database, which is the standard OpenEdge demo database. You need to copy the database so that your test procedures can make changes to it without modifying the version of it in your install directory.
In the Dictionary Startup dialog box, select the option to create a new database, then choose OK:



The Create Database dialog box appears and prompts you for the name of your copy of the database.
Type Sports2000. By default, OpenEdge creates a database named Sports2000 in your working directory. If you’d like the database to be somewhere else, you can choose the Files button next to the New Physical Database Name fill-in field to browse the directory structure for the right location for your database.
After you’ve entered your new database name, select the Start with A Copy of Some Other Database option, and then choose the Files button next to the fill-in field:



Locate the Sports2000 database in your OpenEdge install directory, then double-click that entry or choose the Open button:



The pathname to the database is filled in when you return to the Create Database dialog box:



Choose OK to accept this pathname.
The Connect Database dialog box appears.
Make sure the Physical Name field shows Sports2000 and the Database Type is Progress, then choose OK.

Because you created this database as part of the Data Dictionary startup, which needs to have a database connected before it lets you in, the Data Dictionary main window now opens. You can work with the Data Dictionary at a later time, but just to familiarize you with the database tables you’ll be using in this chapter, go ahead and look at them here.

To familiarize yourself with the Sports2000 database tables:

Select the Customer table from the Tables list, then choose the Fields button on the Dictionary’s toolbar.
All the fields (or columns, to use the equivalent SQL terminology) in the table are shown in the Fields list to the right.
Scroll through the list to see all the fields in the table. You’ll be displaying a few of these fields later, and using others to select a subset of the Customers for display.
Scroll down the list of Tables, then select the Order table.
You can see that, in addition to an OrderNum field, which gives each Order a unique number, there is also a CustNum field, which you will use in "Using Basic 4GL Constructs," to link, or join, the Order table to the Customer record with the same CustNum value.
There’s a lot more to see in the Dictionary. If you want to wander around in the displays, go ahead, but just don’t change anything! Any changes you make might affect steps later in this tutorial. If you make changes to tables or fields, this might invalidate records that are already in the sample database or keep some of your later example procedures from working.
To leave the Data Dictionary, select Database Exit from the Dictionary menu.

Writing your first procedure

Your first Progress procedure will be a real snowplow exercise, something very simple just to get you started with the language. But before you enter this first procedure, you need to make an adjustment to the code—your first change!

There are a fair number of fields in the Customer table, so the resulting formatting of all the fields in a limited display area would be a mess. In fact, one of the fields, the Comments field, is so large that the Progress run-time engine (also known as the interpreter) will balk at displaying it without some guidance from you on how to format and position it.

So it’s better to select just a few of the fields from the table to display, which is more manageable. Select the CustNum field, which is the unique customer number, the Name field, which is the customer name, and the City field, which is part of the customer’s address.

In the Progress 4GL, a list of fields is separated by spaces, so the new procedure becomes:

FOR EACH Customer:     DISPLAY CustNum Name City. END.

To enter this procedure in the Procedure Editor:

Return to the OpenEdge Desktop and choose the icon with the pen and inkwell .
In the Procedure Editor window that comes up, type your block of code:

You might notice the following about this code:

The words FOR and EACH are automatically uppercased as you type them, and colored blue as well. This is because the Procedure Editor uses an intelligent edit control that recognizes Progress 4GL syntax. It not only does color-coding, but can also do autocompletion of common syntax, and can accept abbreviations of common language statements, to help speed up your programming. The editor also recognizes the FOR EACH statement as being the beginning of a block of code and automatically indents the DISPLAY statement, and then unindents the END statement to match the beginning of the block.
You can type the table name Customer with a capital C, or type it in lower-case, or all in capitals, or however you wish. Progress is entirely case-insensitive when it comes to both language keywords and database table and field names. Uppercasing the keywords is just a convention to aid in code readability, but you could type for each or For Each as well and it would work just the same.
Typing CustNum in mixed case is just a convention to aid readability.
When you type the field name Name, it is uppercased and colored blue. This is because NAME is also a keyword in the 4GL. Progress is relatively forgiving in this way: if the Progress compiler, which processes the code you type in, can distinguish between a word that is a field name or table name and one that must be a keyword, it will let you use it that way. It’s a good idea to avoid using keywords as table or field names in your database definition, though. For a list of all the Progress 4GL keywords, see Volume III of the OpenEdge Development: Progress 4GL Reference.

To execute your procedure, press the F2 key on your keyboard. This is the keyboard shortcut for the RUN command. Alternatively, you can select Compile Run from the Editor menu.

The Procedure Editor shows the first set of customer numbers, names, and cities:

To see the next pages of Customer numbers, names and cities, press the SPACE BAR a few times. Press ESCAPE to terminate the display. Otherwise, the display terminates after the last page of Customers has been displayed.

This little three-line procedure certainly does a lot for you, but it doesn’t produce an output display that you would put directly into an application. There are many qualifiers to the DISPLAY keyword in the statement that you can use to adjust its behavior and appearance, some of which you’ll see later on in this chapter. Fundamentally, the DISPLAY statement is not intended to produce polished output by itself for a graphical application. There are other statements in the language you can use to define the windows, browses, toolbar buttons, and other features of a complete user interface. You’ll get to know those in later chapters.

For the purposes of your introduction to the language, leave the display format as it is, so that you can see how the structure of the language itself is put together. That’s the snowplow part of this exercise. You’ll complete a little test procedure here that shows you a lot about the Progress 4GL, but which doesn’t represent the way you will write really finished applications (just as snowplowing shows you a lot about skiing but doesn’t represent how you will actually ski when you’re an expert). To do that, you work together with the development tools to let the tools do a lot of the work of putting together the user interface for you. After only a few chapters, you’ll be building complete application windows and all the logic that goes on behind them.

Basic characteristics of the Progress 4GL

You just wrote about the simplest starting procedure possible. What can you learn from it already?

The 4GL is procedural

Progress is a procedural programming language. That means that you write sets of language statements that you can save in individual, named procedures. The language statements are usually executed or processed in the order in which they appear in the procedure. In a simple procedure such as this one, the statements are executed as they appear. As you move further into building event-driven applications, where the user has a variety of ways to control the application by choosing buttons or making menu selections, you will learn about how to define trigger code that sets up blocks of statements to be executed later on when a particular action occurs.

The 4GL is block-structured

A Progress 4GL procedure is made up of blocks. The procedure itself is the main block of the procedure. There are a number of ways to define other blocks within the main procedure block. The FOR EACH statement and its matching END statement are one example of a nested block, in this case one that iterates through a set of database records and executes all the code in between for each record in the set. There are other block statements you can use for different purposes. Some of them are also iterating, and cause the block to be executed multiple times. Others simply define a set of statements to be executed together. You’ll learn about all of these in later chapters.

A 4GL procedure consists of statements

A Progress 4GL procedure is made up of a sequence of language statements. Each statement has one or more 4GL keywords, along with other tokens such as database field names or variable names. A 4GL statement normally ends with a period. By convention, a statement that defines the beginning of a block, such as your FOR EACH Customer statement, can end with a colon instead. There’s no significance to the end of the line in Progress. A single statement can span multiple lines, and if you wish, there can be multiple statements on a single line. There’s no special syntax needed to break up a statement between lines, but if you have a single element of a statement, such as a quoted string, that is long enough that you need to make it span lines, then end the first line with a tilde character (~).

There must be at least one space (or other white space character such as a tab or new line) in between each token in the statement. Progress is not sensitive to additional white space. You can indent lines of code and put tabs between parts of a statement for readability, and none of this will affect how the statement executes.

Progress is case-insensitive. This means that you can write either a 4GL keyword or a reference to a variable name or database table or field name in any combination of uppercase and lowercase letters. As you have already seen, the intelligent Progress edit control defaults to a convention of capitalizing 4GL keywords. For a list of all the Progress keywords, you can look through the index in the Help Topics submenu of the Help menu (via any of the OpenEdge development tools).

When you define variables in a procedure, and when you define database tables and fields, you must give them names that begin with a letter. After that, the name can include letters, numeric digits, periods (.), hyphens (-), and underscores (_). When you save your 4GL procedure, you give it a name as well, and this follows the same naming rules. Note that, although the 4GL itself has many hyphenated keywords, you should not use hyphens in database table and field names, as well as procedure and variable names in your application. You should follow this guideline because other programming languages that you might want to combine with 4GL procedures often do not allow a hyphen as a character in a procedure or parameter name. And the SQL database access language, which you can also use to manage data in your OpenEdge database using other tools, does not allow hyphens in table and field names.

A good naming convention for all kinds of names in 4GL procedures is to use mixed case (as with the CustNum field) to break up a name into multiple words or other identifiable parts, using the capital letters to identify the beginning of each word or subpart within the name to improve readability of your code.

The 4GL combines procedural, database, and user interface statements

There are three basic kinds of statements in a 4GL program: procedural statements, database access statements, and user interface statements. Sometimes individual statements contain elements of all three. Your first simple procedure contains all three types, and illustrates the power of the language.

The FOR EACH statement itself can be considered procedural, because it defines an action within the program, in this case, repeating a block of statements up to the END statement.

But the FOR EACH statement is also a database access statement, because it defines a result set that the FOR EACH block is going to iterate over, in this case, the set of all Customer records in the database. This simple convention of combining procedural logic with database access is a fundamental and enormously powerful feature of the Progress 4GL. In another language, you would have to define a database query using a syntax that is basically divorced from the procedural language around it, and then have additional statements to control the flow of data into your procedure. In the 4GL, you can combine all these elements in a way that is very natural, flexible, and efficient, and relates to the way you think about how the program uses the data.

The FOR EACH block is also powerful because it transparently presents each record to your program in turn, so that the rest of the procedural logic can act on it. If you’ve written applications that use the SQL language for data retrieval, you can compare the Progress FOR EACH block with a program in another language containing embedded SQL statements, where the set-based nature of the SQL SELECT statement is not a good match to the record-by-record way in which your program normally wants to interact with the data.

The DISPLAY statement shows that user interface statements are also closely integrated with the rest of the program. Progress contains language statements not only to display data, but also to create, update, and delete records, and to assign individual values. All of these statements are fully integrated with the procedural language. In later chapters, you’ll learn how to build your applications so that the procedures that control the user interface are cleanly separated from the procedures that manage the data and define your business logic.

Saving your test procedure

Before you move on to extend your first procedure to learn some of the other 4GL language basics, you should save it out to the operating system. To do this, give your code a procedure name. This follows the same rules as other names, and by convention has a filename extension of .p (for procedure).

To save your procedure in the Procedure Editor, select File Save As. Call the procedure h-CustSample.p and save the file to your working directory, or some other directory you’ve created.

Now you’re ready to extend your procedure in various ways.