In shortest terms, form (called mask then) runner. The philosophy of GenerAll, just like Sale's generators before it, was that the mask's code need not and should not contain everything; what's common to all of them should be in one piece of the code, and whatever is mask specific in another. So to avoid repetition of code and hence fixing it in hundred places.
Now where did we differ. His unos.prg had a separate prg file for each task a mask had to do - draw the frames and text, draw the fields, open its tables, check the record before writing or deletion, refresh the value when moving to another record etc etc. This meant that masks' names were limited to six letters, because the remaining two were _ (underscore) and one extra, specific to the task. I held them all in one file, actually did so in his as well, fixed that for him already back in 1898, because in e.g. material tracking there used to be up to 1600 files in the app's directory, which under Dos 3.1 which read them sequentially, and on the ex tee machines that could take quite a while - there were sometimes a score of them to open, and they were slow to find in such a long list.
I started messing with this runner even within his version, and in november 1992. I even started adding dates to my comments. Not that I thought of writing this back then, it's that I saw it done in various pieces of code from various places, and understood that it was a neat thing to do, and why it was good.
In parallel with this, actually coupled with it, the opisfmm4 was developed, a completely reworked version of Sale's opisfmt.prg, which generated the mask's code. Had to be coupled, because one runs what other generates. Why opisfmt? Well, 'opis' means description, and fmt was the extension of format files. fox didn't have its own mask drawing until FP1.02, so he used the one from dBase (as Big Ćale would say, „it's all of deebase, and a three, and a plus on top of it!“), and these were, well, input formatting files. The .scr files were the metadata and rather binary; .fmt file was commands to draw boxes, text, fields. Opisfmt would import that text into a table (allways called radna.dbf, aka working, temp), and would then go through it a row at a time, chopped that row and dragged out the stuff to put onscreen, which he'd stuff into opisfmt.dbf, a meta table with field name, order, screen position, validation and access code. The last two were, as was a good practice in fox, either an one line expression to evaluate, or multiline piece of code, which would both return a true or false value. He distinguished between the two in an adjacent field (just like FPD later did), 0 or 1 there would mean one or the other. I ignored that, I'd rather count the lines.
When FP came out in 1991, I reworked opisfmm4 (then still called opisfmt, opisfm2 and few other variants) to read what it would churn from its screen drawing gadget (we called it mask, they called it screen, both soon obsolete), which were text files with tab delimited fields, much easier to comb through.
In the beginning (spring 1994.) I had several versions, which ended up with just two - for single records, e.g. for lookup tables*, and for line entry, i.e. documents with items. The line entry was quite complicated to do in the part where I had to control the up-down navigation, which it had to provide, along with check that it shouldn't go above the first line, should create an empty record on the bottom, shouldn't create two empty records, to lift the records below a deleted record... which got hairy immediately. I solved it by having only one visible record with real controls (which we called fields then, wrongly - field is the part of the record which holds one datum; this is an onscreen thing which allows for a value to be entered and later written into a field - well, we didn't have a word for it then), and the other rows were just a picture of this row from the last time it was there. That row moved up and down as needed... How many balls does a good juggler juggle? Zero or one, the rest of them are in the air. No matter how nowadays this combobulation sounds insane and a source of possible bugs, it actually came out quite reliable, robust and with least problems.
The code for both kinds of masks was churned by the same opisfmm4 - it would simply generate two or three routines more for the line input.
There was an another one-line window on the bottom of the screen, where it held a short instruction for F keys, which changed according to context. If the mask was in preview regime (i.e. a key of an existing record was entered, then here take a look at that record), it would be F1 help │ F5 edit from 1. field │ F6 edit from ## field │ F2 delete │ ESC return to append'; in edit mode it would be 'F1 help │ F3 duplicate field Y/N│ F4 duplicate once │ F5 browse | ESC return'.
This F3 F4 thing was invented by Sale, but he wrote it in a very circumspect way - these two keys (and the next two) were defined as hotkeys in an invisible menu, in which he'd stuff the keyboard with some obscure special characters, which then his unos.prg would consider as exit keys, checked which keys they were, and if it was one of those it wouldn't exit but rather do what was needed. It was much easier for me, I didn't have to make do with what mFoxplus 2.1 had, the FP was out and it had a simple and elegant way to bind to any key, no tricks involved.
F3 would turn autorepeat on and off for the current field, and F4 would do an one-time copy of the value from the last record. The autorepeat was a nice feature when a lot of neighboring data were to be entered, like dates of documents. This routine kept these values somewhere all the time - which ones to repeat, and last record's values.
Another cute thing was the multilinguality - all the strings appearing onscreen were defined once in the beginning, in english, hungarian, serbian (latin at codepage 852), serbian cyrillic (by JUS 015), and even juski. One of the strings was named c_konju (you horse you), contained the warning that the last backup was more than a week ago.
----
* 'lookup' is just one use for these tables and doesn't cover the rest of them; serbian 'matična' fits it much better. It means both 'mainstream' (as in the river's stream where it's strong) and 'queen bee'. Means also a nut, one that gets screwed on, though.