Back to work... the holiday is over.
A cryptic comment in opisfmm4 (and then unosc and unosl too, the drivers of generated forms):
", introduced the ucurs(L) field in opisfmt.dbf, with intention that memo fields are not entered into m.vars but rather into a q_[osndbf] cursor, since then the memory consumption doesn't grow squarely with the text length. by the way, the odd members of the _tabv() array now have numeric values - 1 not conforming to f3f4 (it's a m.var or array member), 0 - normal field, 1 - memo field, 2 - normal field autodup, 3 - memo, autodupchecking the definedness of odd members of _tabv() is now not in unosc, but rather in the generated code."
Ouch, to explain this... what I wrote there and by what miracle it all worked in the first place. The _tabv array was a list of values and some properties of those values, the properties being in the odd ones, the values in the even ones. The f3f4 behavior (inherited from Sale) was the autocopy of value from previous record; f3 would turn it on or off for the current field, f4 would copy once. The initial state was set when designing the form - these field will autocopy, others won't, and that went into the odd members of the array. The even members held those last values.
I saw to avoid what happened to many a beginner, when they entered values straight into the record, and then if the user cancels the entry, they have to erase the record, or blank it, or mark it as unfinished, then write more code to handle these oddball records, making their lives even more complicated. Instead, I did entry into memory variables, and upon pressing enter on the last field, the record was inserted or updated to the table. And that's where memo fields, i.e. texts of unkonown length, fucked my goats. That's where the user could do anything, write erase paste move and whatnot, and could undo his last actions, which meant the previous moves, or whole states, were memorized somewhere, which ate memory. And somehow I found out that if it didn't go into a memory variable but a memo field in a table or cursor, it didn't eat it. That is, it did use some memory somewhere, but in a different area where it had reserves, and would return it as soon as I moved to a different record. Which is why I invented this q_[osndbf] cursor, named same as the main table, just prefixed with q_, which would always have one record. It worked like a dragon for as long as GenerAll was in use.
Of course, all these changes in the generator required counterparts in unosc.prg.