Files

Marius Mutu b5a7108f34 docs: cercetarile comune trec in COMUN, reziduul #6 dispare, progres.md la zi

Curatenie ceruta dupa inchiderea lui #6. Folderul cercetare\ NU se putea sterge
in bloc: plan_13 se sprijina pe el cu 85 de trimiteri, deci e baza de dovezi a
planului aflat in lucru. Impartirea:

- 14 cercetari trans-proiect trec in COMUN\docs\cercetare\ - valuta si curs,
  TVA/VANZARI, consumatorii VANZARI din toata suita, integrarile #10/#11/#12,
  watchdog VFP, proiectarea Oracle a lui S5, view-ul VVANZARI_ARTICOLE. Nu sunt
  ale ROAFACTURARE, iar #10/#11/#12 se reiau chiar din ele.
- 20 de rapoarte de executie ale lui #6, nereferite de nimic viu, sterse.
- 91 raman, neatinse.

Trimiterile catre handoff-urile si diff-urile intermediare deja desfiintate au
fost curatate peste tot (39 de fisiere): 50 catre handoff-uri, 37 catre diff-uri
aplicate, plus caile celor mutate in COMUN. Zero trimiteri rupte ramase.

progres.md preia rolul de predare: ce ramane din #6 (cele sase documente
parazite, cele doua esecuri reale din S8 pe factura din aviz), cifrele de test
citite din log, si cele doua capcane de mediu platite - .FXP vechi executat in
locul .prg-ului, si GETFONT() care atarna un formular instantiat fara goApp.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SN8snvkk94KuhWwoXUUey3

2026-08-11 22:31:42 +03:00

7.9 KiB

Raw Blame History

S4b etapa 2 — butonul, dialogul si verificarea la salvare

Continuarea lui handoff intermediar (sters), sectiunea „S4b etapa 2". Diff-ul complet: diff aplicat (sters) (342 randuri adaugate, 0 sterse, un singur fisier atins: COMUN\clase\omodificari.vc2).

STARE: WRITE-BACK FACUT, NECOMIS. omodificari.vcx/.vct sunt regenerate (11.08.2026 09:34), textul e cel canonic FoxBin2Prg. Nimic nu e intr-o stare periculoasa.

Verificare	Rezultat
compilare la regenerare (`txt2vcx.ps1`)	`P1,E0,S1,X0` — 0 erori
fidelity check binar -> text -> octeti, in staging	trecut (`OK`)
`git_sync.ps1` dupa write-back	0 conversii, 464 la zi, 0 esecuri — text si binar sincrone
textul dupa write-back	342 adaugari, 0 stergeri fata de HEAD
octeti `>0x7F` (diacritice cp1250)	6 inainte, 6 dupa, aceleasi valori (170, 227, 254)
clasele noi chiar in binar (`.vct`, nu in text)	`frm_sincronizare_articole` x15, `propunere_afisata` x27, `cmdSincronizeazaArticole` x3, `lblAvertisment` x2

Prima incercare de write-back a esuat la fidelity check — ordonarea canonica FoxBin2Prg difera de cea scrisa de mana (intrarile OBJECTDATA ale header-elor de grid se genereaza singure, ADD OBJECT-urile se sorteaza alfabetic, optDirectie.Click merge dupa Unload). Am adoptat textul canonic din staging si am reluat — nicio pierdere de continut, diferentele erau doar de ordine si spatii.

Ce contine

Piesa	Unde
butonul `cmdSincronizeazaArticole` (Left=350, Top=0, W=250, H=22, TabIndex=6)	`ADD OBJECT` in PAGE3
toggle-ul de `Enabled` pe `lArticoleReadOnly`	`frm_modific2024.Show`
`cmdSincronizeazaArticole.Click`	`frm_modific2024`
`AfiseazaDialogSincronizareArticole`	`frm_modific2024`
verificarea la salvare	`frm_modific2024.inainte_de_do_termin`, imediat inainte de `RETURN m.llRet`
clasa `frm_sincronizare_articole` (derivata din `frm_termin_renunt`)	la finalul fisierului

TabIndex 6 e liber in PAGE3 (folosite: 3, 4, 5, 20 — verificat).

Ce am schimbat fata de patch-ul partial al agentului mort

Patch-ul din diff aplicat (sters) era mai complet decat il descria predarea (avea si verificarea la salvare, in metoda corecta). Cinci corectii:

1. Lipsea cmdSincronizeazaArticole.Click — butonul exista, dar nu facea nimic. Adaugat, cu aceleasi garzi ca la celelalte doua butoane din PAGE3.

2. Gridul ramanea nelegat dupa schimbarea directiei. ConstruiestePropunereSincronizare face Use In propunere_sincronizare + CREATE CURSOR la fiecare apel (ofacturare_editare.prg:584-589), deci un grid legat la design-time de acel cursor isi pierde legatura la primul click pe radio. Solutie: gridul se leaga de propunere_afisata, un cursor cu structura identica creat o singura data in Load (inainte de instantierea controalelor, ca sa existe cand gridul se leaga) si doar golit + reumplut la fiecare recalcul. Nicio reasignare de RecordSource la runtime.

3. Declansarea la salvare era pe Reccount(...) > 0 — ar fi deschis dialogul la fiecare salvare a oricarei facturi cu articole nestocate sau in valuta, pentru ca acelea produc linii N-A in propunere (contract, punctele 1 si 3). Acum se numara doar Modificare / Adaugare / Semnalare: divergente reale. N-A inseamna „nu se poate compara", nu „difera", si nu mai opreste pe nimeni la salvare.

4. Pemstatus(This.oFormArticole, ...) fara garda de tip — oFormArticole are valoarea implicita .F., iar Pemstatus pe un logic da eroare. Adaugat Vartype(...) == 'O'.

5. Adaugata eticheta de avertisment ceruta de propunere_s4b_sincronizare.md punctul 6 („Propunere calculata automat - verificati valorile inainte de aplicare"), plus curatarea cursorului in Unload.

Verificat, nu presupus

Ce	Cum
`_frmbase.WindowType = 1` (dialogul e modal)	`_frm_base.vc2`, blocul `PropValue`
`do_termin` cheama `inainte_de_do_termin()` si inchide doar pe `.T.`	`_frm_base.vc2:364-374`
`frm_termin_renunt` are `But_termin1` + `But_renunt1`	`_frm_child.vc2:23-51`
tiparul apelantului (`CreateObject` + `Show`, citirea lui `gnButon`)	`ofacturare_comun.vc2:4651-4656`
clasele `_optiongrup`, `_grdrow`, `_label` exista	`_baza.vc2:435`, `_grd_base.vc2:445`
`InputMask = (get_mask(12,gnPCANT))` e tipar real	`omodificari.vc2:12374` s.a.
`_frm_child.vcx` nu are nevoie de `SET CLASSLIB`	precedentul `frm_modifica_articol_factura`
toate formularele sunt pe `DataSession` implicit (1)	niciun `DataSession` in `_frm_base`/`_baza`/`omodificari`
`SET SAFETY OFF` global (pentru `ZAP`)	`COMUN\programe\proceduri.prg:5`
octetii cp1250 din fisier sunt neatinsi	cens `>0x7F` = 6 inainte si dupa; diff-ul are 0 stergeri

Netestat: nimic nu a fost rulat. Dialogul e UI, deci nu e testabil -A -T (aceeasi limitare ca frm_articol_factura, propunere_s4b_sincronizare.md punctul 7). Logica pura din spate ramane acoperita de test_s4b_sincronizare.prg (35/0), neschimbata de aceasta livrare.

Doua lucruri de confirmat cu Marius

A. Aplicarea la salvare ocoleste validarile deja rulate. Daca utilizatorul apasa „Aplica" in dialogul deschis la salvare, tvd se modifica dupa ce validarile din inainte_de_do_termin (pret de achizitie, linii sterse) au trecut deja. Alternativa ar fi reluarea validarilor dupa aplicare — nu am facut-o, ca sa nu extind scopul.

B. N-A nu mai declanseaza dialogul la salvare (corectia 3). E o alegere de produs facuta de mine: altfel dialogul ar aparea la fiecare salvare pe documentele in valuta.

Defect preexistent gasit pe drum — REPARAT (aprobat separat, 11.08.2026)

omodificari.vc2:16495, in frm_modific2024.pgfArticole.PAGE3.cmdAdaugaArticol.Click:

IF !Used('tvd') OR !This.lAreArticoleVanzari OR Thisform.lArticoleReadOnly

This e butonul, nu formularul — lAreArticoleVanzari e proprietate a lui frm_modific2024 (omodificari.vc2:12987, :14788, :14795, :14802 o folosesc corect, toate din metode ale formularului). VFP scurtcircuiteaza OR: cand tvd exista — adica in exact cazul in care butonul e activ — primul termen e .F. si se evalueaza al doilea, pe buton, unde proprietatea nu exista. Nu exista metoda Error in _frmbase/_baza/omodificari care sa inghita eroarea.

Concluzia: „Adauga articol" dadea eroare la orice click real. Suitele existente nu prind asta pentru ca apeleaza metodele formularului, nu simuleaza click-ul.

Nu era una, ci doua. Cautarea sistematica dupa acelasi tipar (proprietati ale formularului accesate cu This. din metode de obiect) a mai gasit una, in aceeasi metoda, la :16565:

AddProperty(poDate, 'tip', This.nTipVanzare)

Ambele reparate cu Thisform.. In tot frm_modific2024 nu mai exista alta: cautarea a acoperit lArticoleReadOnly, lAreArticoleVanzari, nIdVanzare, nTipVanzare, pgfArticole, ActualizeazaBaraTotaluri, AdaugaLinieTvdDinArticol, calculeaza_valori_articol, filtrata pe metode de obiect (.Click/.Valid/.InteractiveChange/...). Celelalte 4 folosiri ale lui This.lAreArticoleVanzari sunt in metode ale formularului (ActualizeazaBaraTotaluri, Show) si sunt corecte.

Nu intra in changelog: 2.11.15 nu e inca in productie, deci e un defect al codului nelivrat.

Changelog

Paragraf nou in blocul 2.11.15 (:nou:), nu versiune noua — 2.11.16 a fost dat inapoi „pana la punerea in productie" (commit 09f9d47). Descrie butonul, alegerea directiei, liniile marcate si lasate neatinse, si comparatia de la salvare cu optiunea de a salva fara sincronizare.

Fisierul changelog_roafacturare.txt avea deja un octet stricat in HEAD (EF BF BD, un © transformat candva in U+FFFD, in intrarea despre „ROA Romfast SRL"). E preexistent, nu l-am atins; cenzul ramane 3 octeti >0x7F inainte si dupa editarea mea.

Ce urmeaza

Rebuild roafacturare.exe din IDE si testul pe ecran. Metodele .vcx sunt deja compilate de txt2vcx.ps1; EXE-ul nu.
Punctele A si B de confirmat.

7.9 KiB Raw Blame History