Assuming your application uses INFLD, at least for input, you can activate the GUI version globally by adding SBR=INFDEF:|G to miame.ini. Without any changes to your application, this will cause INFLD to use Windows edit controls for field editing. In the case of date fields, it will use a date picker control. For fields with a list of possible choices defined in SETDEF, it will use a combo box. However, unless your application uses INFLD to display data (as well as to edit it), the enhancement will only affect the field that is being editing, and to some extent the fields that have been edited on the current screen. As each field is updated by INFLD, it will, by default, be converted to a sunken static text field. You can force it to redisplay the updated field using an edit box by adding |E to your SBR=INFDEF statement. To go one step further, you can use ||C instead of |E, which will leave the date pickers and combo boxes in place also. If you don’t like the date pickers and combo boxes, use |g instead of |G.
In our first attempt with |G active, our screen looks like this. The only thing which has changed so far is that the field we are actually editing, in this case, Social Security, is a Windows edit box, and the fields which have been edited and redisplayed by INFLD are displayed in sunken boxes.
To get INFLD to redisplay updated fields using the same kind of edit box as when editing, you can add ||C to the SBR=INFDEF specification, to get the result as shown below (after editing fields 3-7 and 10-11):
The two dates in the example above have a dropdown button next to them, which brings up a date picker calendar control. If you don’t like this effect at all, and just want to use a regular edit box to edit dates, then replace |G with |g. If you want to us the date picker for editing, but don’t want it to display with the dropdown button, then use |E in place of ||C.
The display above is starting to look a lot like a regular Windows-style program, but there are still some deficiencies. One is that not all of the fields display the same way. This is because the program uses PRINT to display data, which produces the plain text version, and then when we edit a field, INFLD redisplays it using one of its formats (sunken gray box, white edit box, etc.). Furthermore, some fields even get redisplayed using PRINT immediately after editing, which means that even after editing them we don’t get the edit box or sunken rectangle. (In the above screen, this is the case with Marital Status, which gets input as a numeric code, then redisplayed as text. This is also the case with the fields 12-15.)
Speaking of field numbers, the very idea of numbering fields on the screen is somewhat unusual in a Windows program. The idea of an "Any Change? " prompt asking you which field number to change is even more questionable. To deal with these and other differences between our legacy program and a modern Windows-style program, we’ll need to make some actual improvements to the programs. But before getting into that, we’ll first finish up discussing some of the display adjustments and other GUI enhancements which can be done without any program changes.
Subtopics
