Progress
AppBuilder
Developer’s Guide
Reading and Writing 4GL Widgets
When you use AppBuilder, you manipulate widgets in a largely WYSIWYG fashion, and AppBuilder generates the 4GL code later to make it all work as you intend. Because of this, it is natural and convenient to think of the widgets themselves as being the variables they represent. AppBuilder encourages this by using the widget identifier as the storage identifier. Thus, when you place into the workspace a Slider widget, for example, identifying it as object iExampleSlider that displays a certain integer subrange, etc., AppBuilder will later generate a 4GL statement such as this one:
The syntax of this statement can give the impression to a programmer familiar with other languages that, in the 4GL environment, basic widgets are mere visual expressions of data (VIEW–AS) handled entirely at the level of the r-code interpreter. If that were so, then an assignment statement such as:
would immediately cause (in this example) the knob of the Slider widget to move halfway up the track.
The actual situation is slightly more complicated.
Each widget represents two storage locations, not one. There is the storage location that you identify with the widget when you create the instance—iExampleSlider in the example—plus an anonymous storage location conceptually allocated in the system display buffer. These locations—main memory and screen display—are independent of one another, from the standpoint of your code.
User keyboard and mouse actions modify the anonymous location in the display buffer; assignment statements modify the identified location in main memory. A change made to one of the locations is not automatically reflected in the other location. You must explicitly close that gap by copying changes from one storage location to the other whenever required by the logic of your program.
If you want changes made to a variable to appear on the display, use DISPLAY:
If you want changes made to the display to reflect in the variable, use ASSIGN:
The benefit of such a disconnected model is speed. Since device i/o is very slow compared to operations on memory, it is better not to do device i/o except when necessary. The Progress i/o model helps you manage that problem.
NOTE: The 4GL is much more complex, sophisticated, and adaptable than this brief introduction might imply. DISPLAY and ASSIGN are not the only routines that can move data between the two storage locations. Use this information as a way to make things happen while you are learning more subtle methods.
Copyright © 2004 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095 |