Zámerom je dosiahnuť čo najkratšiu odozvu. Stav - podľa obrázka.
Mám tri podformuláre:
- ľavá i stredná časť používajú tie isté SQL. Dedia rovnaké triedy
- pravá strana je samostatný podformulár s 12 totožnými záložkami
Všetky tri časti pracujú s kritickou tabuľkou DEPOSITS. Rozdiel je v detailoch.
.
Ľavá strana "Byty a vlastníci" sa vždy mení rovnako pri zmene SVB. Vždy stačí jediný DataSet.
Stredná a pravá časť sa aktualizujú pri zmene vlastníka vľavo. Pri zmene:
- SVB použiť "centrálne" SQL = jediný DataSet. Dva kusy
- vlastníka použiť vlastné, zdedené SQL - nezávislá činnosť
"Listovanie" v strednej a pravej časti nevyvoláva priamu reakciu.
.
Na všetko mám vytvorené vlastné objekty. Pri otváraní formulára, či zmene SVB (totožné činnosti) sa vplyvom dedenia všetky akcie vykonajú 3x. Nechcem to rozbiť na tri samostatné formuláre.
Moja predstava:
Pri zmene SVB volať všetky tri SQL len jediný raz a použiť ich vo všetkých troch podformulároch. To by prakticky trojnásobne skrátilo čas odozvy!
Pri zmene vlastníka by sa zachoval súčasný stav. Každý podformulár, vďaka dedeniu, si všetko spravuje samostatne.
.
Niečo také som nikdy nerobil a netuším ako to mám metodicky zrealizovať. Ako na podformulár v pravo?
Všetky tri triedy majú zhodnú štruktúru pre GUI - vizualizácia údajov.
type
TCreditOwner = class(TOwnerBasic) // Ľavá časť
public
constructor Create(const ANavigator: TjstIBCNavigator); override;
constructor CreateForm(const AForm: TBasalForm; const ANavigator: TjstIBCNavigator);
end;
.
TCreditDeposit = class(TDepositBasic) // Stredná časť
public
constructor Create(const ANavigator: TjstIBCNavigator); override;
constructor CreateForm(const AForm: TBasalForm; const ANavigator: TjstIBCNavigator);
...
end;
Opäť veľmi dlhý príspevok. Žiaľ.
PS: to je čo za debilné správanie. Mal som veľkú prílohu. Tlačidlo "Zpět" a príspevok nikde!!!
