comun/skills/roa-vfp-frx-report/references/reportbehavior-80-90.md

REPORTBEHAVIOR 80 vs 90 (rapoarte ROA)

Aplicatia randeaza rapoartele cu REPORTBEHAVIOR 90: FoxyPreviewerSimple (COMUN\programe\oexport.prg:1733-1738) seteaza gnReportBehaviour daca e numeric, altfel 90, apoi lanseaza REPORT FORM ... PREVIEW (oexport.prg:1746-1747). Verificarea finala se face la 90, pentru ca la 90 randeaza aplicatia.

Diferente verificate (aceeasi sursa .frx, r3)

• Obiectele din Group Header cu SUPRPCOL=0/SUPGROUP=0 NU se randeaza la 90 (pe primul grup), dar se randeaza la 80. Cu SUPRPCOL=3 + SUPGROUP=6 (grupul 1), cum le scrie Designer-ul, GH randeaza normal la 90 (dovedit pe pvcasare_mf, 24.09.2026). Continutul per grup poate sta in GH cu aceste valori, sau in Page Header cu GH HEIGHT=0, PAGEBREAK=.T..
• Obiectele plasate in regiunea separatorului (VPOS intre START+HEIGHT al benzii si START-ul benzii urmatoare, adica in cei 2083.333 FRU) se randeaza la 80, dar NU la 90. La 90 motorul taie strict la continutul benzii.
• Test izolat: label la VPOS 29500 (in separatorul de dupa Page Header) - apare la 80, dispare la 90.

Dovada numerica vs dovada de aspect

• La 90 NU exista cale text curata headless: TO FILE ... ASCII trece prin listener si scrie BINAR (nu agata, dar nu e text lizibil); OBJECT TYPE 1 se BLOCHEAZA headless.
• Dovada numerica (randuri, totaluri) se face cu 80 + REPORT FORM ... TO FILE <txt> ASCII NOCONSOLE; dovada de aspect si verificarea finala se face cu 90 + PREVIEW -> PNG (vezi preview-png.md).
• TO FILE ... ASCII (80) trunchiaza la 80 de caractere/linie (r6): capetele din dreapta pot aparea taiate ("Amortizarea pana l") fara ca raportul sa fie defect - e limita grilei ASCII, nu a paginii. Nu confunda cu trunchierea de camp ("..."/"***"), care se vede doar pe PNG.