roaregistratura/docs/analiza_registratura_adaugare_editare.md

Analiza: adaugare/editare document in registratura + lista documentelor + fonturi

Data: 23.07.2026. Analiza pe surse (fara modificari de cod). Referintele de linie sunt in fisierele text FoxBin2Prg (.vc2), sincronizate cu binarele la data analizei.

1. Fluxul actual (cum functioneaza azi)

Fereastra principala (ofundal_registratura.vc2, clasa pg_meniu_princ):

• Page2 "Lista documentelor" = ct_registratura (grid pe cursorul cRegistratura, incarcat de viz_registratura din Programe\oproceduri_roaregistratura.prg).
• Page3 "Datele documentului" = ct_part_nr_data (Partener / Nr. doc / Data doc + butonul Modifica/Salveaza cu lacat) + ct_date_generale (bara outlook cu butoanele Date generale / Referinte / Observatii / Documente atasate, care deschid formulare separate podg_dg, podg_referinte, podg_obs, podg_link).
• Starea editarii este ct_part_nr_data.llock (.T. = blocat). Butonul Command2 comuta: la deblocare afiseaza "Toate modificarile au efect imediat!", la a doua apasare ("Salveaza") apeleaza modifica_reg_dg.
• Salvarea reala e modifica_reg_dg (oproceduri_roaregistratura.prg:100) -> apel PL/SQL pack_registratura.modifica_registratura.
• Adaugarea (ct_registratura.do_adauga, ferestre_registratura.vc2:1206): aloca numar intern (oGeneratorNumere, seria 10), insereaza un rand GOL prin pack_registratura.adauga_registratura, apoi sare pe Page3. Documentul nou are id_part NULL pana alege utilizatorul partenerul.

2. Problemele identificate (cauze exacte)

P1. Prompt "Doriti sa salvati modificarile facute?" aparut "din senin"

Doua locuri intreaba automat cand llock = .F.:

• outlook2003bar.vc2:1009 (do_arata_formular): orice click pe un buton din bara laterala (Date generale, Referinte, Observatii, Documente atasate) intreaba si, la Da, ruleaza modifica_reg_dg.
• ofundal_registratura.vc2:286 (Page3.Deactivate): la parasirea paginii, la fel.

Deci scenariul raportat: utilizatorul apasa Modifica (deblocare), apoi navigheaza (ex. deschide sectiunea Date generale ca sa completeze campuri sau vrea partenerul) -> prompt de salvare -> Da -> eroare, pentru ca documentul nou are partener NULL.

P2. Eroarea la partener NULL

modifica_reg_dg, linia 111:

lcId_part = Alltrim(Str(loRegistratura.id_part))   && fara NVL!

Str(.NULL.) -> NULL, concatenarea in lcSql propaga NULL -> goExecutor.oExecute(NULL) -> eroare. Aceeasi problema potentiala: lcNr_pag (linia 123, fara NVL) si Dtos() pe date NULL (liniile 114/116 dau sir gol la NULL — tratat in IIF, ok).

Validarea de partener exista doar in Command2.Click (ramura Salveaza, ferestre_registratura.vc2:332), dar:

• ruleaza DUPA ce campurile au fost deja blocate si caption-ul pus pe "Modifica" (stare inconsistenta: mesaj "Alegeti partenerul!", dar formularul ramane blocat si nesalvat);
• celelalte doua puncte de salvare (P1) NU au deloc validarea.

P3. Flux confuz Modifica/Salveaza

• Mesajul de la deblocare ("Toate modificarile au efect imediat!") e fals: modificarile de date generale se salveaza doar la "Salveaza"/prompt; doar ck_avizat.Valid scrie imediat.
• Dupa adaugare (do_adauga) documentul nou apare pe Page3 blocat: utilizatorul mai trebuie sa apese Modifica inainte sa poata alege partenerul — pas inutil si sursa promptului din P1.
• Raspunsul "Nu" la prompt arunca modificarile fara re-citirea datelor originale: goRegistratura ramane cu valorile editate (afisare inselatoare pana la refresh).

P4. Lista documentelor: incarcare integrala + pozitionare pe primul

• viz_registratura incarca TOATE inregistrarile cu sters=0 din vregistratura (fara filtru initial pe ultimul document), apoi Go Top -> se vede inceputul bazei.
• Page2.Activate apeleaza do_cauta() la fiecare activare; fara bife, filtrul devine STERS=0 -> reincarcare integrala la fiecare revenire pe lista.

P5. Fonturi

• Clasele COMUN de baza (_baza.vcx: _textbox, _label, _checkbox, _grid etc.) au deja Arial 10 — controalele derivate din ele sunt OK.
• In proiect insa:
  • ferestre_registratura.vc2: 75 aparitii FontName = "Arial Narrow" (gridul grid_registratura + toate coloanele/headerele/text-urile, checkbox-urile de filtru);
  • onom_clienti.vc2: 79 aparitii;
  • ct_part_nr_data, ct_date_generale si mare parte din frm_dg_date_generale folosesc controale baseclass VFP (textbox/label/checkbox/commandbutton fara clasa COMUN) fara FontName -> mostenesc fontul formului sau raman pe default (Arial 9).

P6. Alte observatii (fragilitate, de semnalat)

• Ck_tipdoc e legat de classlib ..\..\roacont\comun\clase\caut_ora.vcx (referinta cross-proiect catre ROACONT, nu COMUN-ul propriu) — ferestre_registratura.vc2:589.
• cmdFel_document/cmdNresp/etc. au Picture din ..\..\roacontracte\grafice\find.bmp (alt proiect).
• Proiectul nu a mai fost recompilat de mult cu COMUN-ul curent -> build necesar in VFP9 IDE dupa aplicarea modificarilor.

3. Modificari propuse (minime, in ordinea prioritatii)

M1. modifica_reg_dg — garda si NVL (oproceduri_roaregistratura.prg)

• La inceput: daca Isnull(toRegistratura.id_part) Or Empty(toRegistratura.id_part) -> AMESSAGEBOX('Alegeti partenerul inainte de salvare!') si Return .F..
• lcId_part/lcNr_pag cu Nvl(...); functia sa intoarca .T./.F. (succes), ca apelantii sa poata reactiona.

M2. Punct unic de salvare + prompt doar cand exista partener

• In do_arata_formular (outlook2003bar) si Page3.Deactivate: daca llock=.F. si id_part NULL -> mesaj "Alegeti partenerul!" si fara apel modifica_reg_dg (raman in editare in cazul barei laterale; la Deactivate se renunta explicit).
• In Command2.Click (Salveaza): validarea partenerului INAINTE de blocheaza_campuri(); se blocheaza doar dupa salvarea reusita.

M3. Dupa adaugare, intra direct in editare

In do_adauga / la comutarea pe Page3 pentru document nou: llock=.F., deblocheaza_campuri() (inclusiv pe formularele podg_* deschise) si focus pe cmdDenumire -> utilizatorul alege direct partenerul, fara pasul Modifica. Se elimina si mesajul fals "Toate modificarile au efect imediat!" (sau se inlocuieste cu "Apasati Salveaza pentru a pastra modificarile").

M4. Lista: initial doar ultimul document

• viz_registratura primeste filtrul initial: sters=0 and id_reg = (select max(id_reg) from vregistratura where sters=0) (de validat sintaxa cu gencursor la implementare; alternativ ordonare desc + rownum=1).
• do_cauta: daca nicio bifa de filtru nu e activa, pastreaza filtrul "ultimul document" in loc de STERS=0 (incarcare integrala doar la cautare explicita).
• Dupa incarcare: pozitionare pe ultimul (unicul) rand -> martor pentru ultimul numar de inregistrare.

M5. Fonturi Arial 10 — prin rebazare pe clasele din _baza.vcx (decizie Marius)

• Controalele baseclass VFP din proiect se rebazeaza pe clasele COMUN care au deja Arial 10: textbox -> _textbox, label -> _label, checkbox -> _checkbox, commandbutton -> _commandbutton, optiongroup -> _optiongrup (toate OF "..\comun\clase\_baza.vcx"). Vizate: ct_part_nr_data (txtClient, txtNumar, txtData_ctr, cmdDenumire, Command2, Label3/4/9), frm_dg_date_generale (txt*, cmd*, Label*, ck_avizat, optIE) si textele/checkbox-urile din coloanele gridului grid_registratura.
• Se ELIMINA suprascrierile explicite FontName = "Arial Narrow" (75 in ferestre_registratura.vc2, 79 in onom_clienti.vc2), astfel incat controalele sa mosteneasca Arial 10 din clasele de baza; gridul (_grdrow din _grd_base.vcx) ramane pe mostenirea lui odata scoase suprascrierile.
• Controalele deja derivate din COMUN (_lbbase, but_*, clb_tx_simplu, ck_filtru_* etc.) raman neatinse.
• Atentie la latimi: Arial e mai lat ca Arial Narrow — de verificat vizual coloanele gridului si etichetele dupa schimbare (conventie_ux_formulare.md).
• Nota tehnica: rebazarea se face in textul .vc2 (schimbarea AS <clasa> + ClassLib in markerul END OBJECT), cu fidelity-check la write-back; e o modificare mai invaziva decat schimbarea de font per control — de testat intai pe un singur control, apoi extins.

M6. Recompilare

Dupa aplicarea M1–M5: BUILD proiect in VFP9 IDE (recompilare cu COMUN-ul curent), apoi git_sync si commit (dupa aprobarea diff-urilor).

4. Testare

Scripturi noi in Teste\ (rulare headless vfp9.exe -A -T, log in Teste\log_*.txt, mediu CENTRAL / MARIUSM_AUTO conform reguli_lucru.md):

• test_init_env_registratura.prg — init mediu neinteractiv pentru ROAREGISTRATURA (SET PATH/CLASSLIB/PROCEDURE preluate din Programe\roaregistratura.prg).
• test_registratura_form.prg — incarca cursorul listei (viz_registratura), verifica existenta cursorului, numarul de inregistrari si pozitionarea pe ultimul document; instantiaza containerul ct_registratura pe un form ascuns.
• test_registratura_adaugare.prg — fluxul de adaugare SI editare: alocare numar intern, adauga_registratura, apoi modifica_reg_dg cu partener NULL (se asteapta eroare/refuz — reproduce bugul P2), cu partener valid (se asteapta succes), apoi EDITAREA documentului (modificare descriere/nr_pag/data + re-salvare + verificare in baza — fluxul Modifica -> Salveaza).

NOTA: scripturile NU se ruleaza pe baza de productie (JCSSERVER/CONTAFIN_ORACLE). Daca schema de test nu contine pack_registratura, testele de adaugare logheaza eroarea si se opresc curat (fara scrieri partiale).

5. Ce urmeaza

Dupa aprobare, implementarea se livreaza ca diff-uri pe fisierele text (docs\diff_runda1_*.patch), write-back cu txt2vcx.ps1 doar dupa OK.