skip to main content
OpenEdge Development: AppBuilder
Introduction : Reading and writing ABL widgets
 
Reading and writing ABL widgets
When you use AppBuilder, you manipulate widgets in a largely WYSIWYG fashion, and AppBuilder generates the ABL 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, AppBuilder later generates an ABL statement such as the following:
 
DEFINE iExampleSlider AS INTEGER INITIAL 0
  VIEW-AS SLIDER MIN-VALUE 0 MAX-VALUE 16384.
The syntax of this statement can give the impression to a programmer familiar with other languages that, in the ABL Virtual Machine (AVM), 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:
 
iExampleSlider = 8192.
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:
 
iExampleSlider = 8192.
DISPLAY iExampleSlider WITH FRAME fMain.
/* replace fMain with the actual identifier of the frame that encloses the
   iExampleSlider widget */
If you want changes made to the display to reflect in the variable, use ASSIGN:
 
/* copy the current value from the anonymous location */
ASSIGN iExampleSlider.
 
/* insert code here that uses the widget value */
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 AVM I/O model helps you manage that problem.
Note: ABL 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.