# 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.