D3? Ako se dobro sjećam, ja sam D3 koristio negdje tamo 1997. godine? Zašto onda ne pređeš na lazarus koji je bar na nivou D7, multiplatformski je, i još ponešto, a još je i potpuno besplatan?
Hajdemo redom:
Imena varijabli, a samim time i imena objekata (kontrola). Iako u današnje vrijeme mađarska notacija gubi smosao u strong type compilerima, razmisli bar o nekom modrijem i uniformnijem davanju naziva. To je navika koja se na početku usvaja, u spurotnom ćeš (p)ostati programer koji jednog dana ne može održavati ni vlastiti kod, a kamoli da to čini netko drugi, ili da radiš u timu. Varijable naziva prvi, drugi, treci baš i nisu nesšto deskriptivne.
Izdvajanje u procedure ili funkcije. Gledam Unit5 (ista opaska oko davanja imena unitu), na ne znam koliko eventhandlera vrtiš one show/hide metode. Nije li jednostavnije napraviti neku funkciju kojoj proslijediš listu, ili container po kojem sama prođe i posakriva sve što ne želiš i prikaže što želiš (ili obrnuto). Ako nita drugo možeš reći i with kontrola1, kontrola2, kontrolan do visible := False; ili nešto slično. Kod prvog sistema danas-sutra ako dodaješ jednu kontrolu na formu ne moraš razmišljati gdje je sve moraš dodavati na 6 mjesta i sl. a kod drugog je sve znatno preglednije i kraće. Nije mudrost isprogramirati nešto. Treba to isprogramirai da uvijek radi jednako, i da danas-sutra kod bilo koje promjene i dalje radi jednako uz minimalne ili nikakve modifikacije. Kužiš?
Treće, opet "početnički gaf". Dohvaćanje polja prema indexu polja je loša, loša i još jednom loša ideja. Smislena je i koristi se samo kod dohvata nepoznatog broja polja, nepoznatog tipa i sl. primejrice kad želiš sve nazive polja nekog dataseta potrpati u neki combo box, ili nešto prebrojiti, preskočiti, i sl. Polja složena po indexu su (osobito kod TTable) vezana uz redosljed polja u tablici. Ako netko na bazi ubaci neko polje zbog nekog x razloga i poremeti prijašnji redoslijed polaj tvoj program je doslovno mrtav jer ni vrijednosti polja ni tipovi podataka neće odgovoarati onome što si ti imao ranije.
Kloni se direktnog rada s TTable i uporabom filtera i sl. Maksimalno koristi Query i select kojim ograničavaš što sve dobiješ na client (makar to bilo na istom stroju). Ako već imaš podatke na clientu, tada možeš dodatno koristiti filter, no vući sve na client pa primjenjivati filter ili iterirati kroz cijelu tablicu i raditi locate ili sl. je "clipperaški način razmišljanja". kažem to iz iskustva jer sam i sam prije poprilično doba radio i na clipperu i znam koje sam greške radio prelazeći na Delphi, a čak sam i imao iskustvo u jezicima tipa VB.
Formatiranja i validacije.
Ako to već ne radiš na bazi (a na paradoxu ni ne možeš), razmisli o formatiranju i validaciji u definicijama polja. Isto tako, razmisli o formatu polja koji se mijenja ovisno ko tome kako štefica (neka baba iz knjigovodstva) promjeni svoje formate datuma ili decimalni separator (jer to recimo traži neki drugi program) u tvom programu bi se moglo svašta događati.
Nisam gledao kako stojiš s indeksima i kako radiš s primarnim ključem? Kod Paradoxa se pazi zamke koja se zove Auto ID tj. njegov interni mehanizam inkrementacije. Bolja je varijanta emulacije sekvenci/generatora u kojoj svaki put sam svojom procedurom inkrementiraš taj brojač i rezerviraš sekvencu za svoj record. Probaj program višekorisnički (makar ga 100% vremena koristio samo jedan jedni čovjek na jednom računalu) i kako radi na mreži. Paradox opet, iza sebe ima priču o locking tablicama i shared direktoriju na mreži jer ako to ne složiš kako treba imaš problema s višekorisničkim radom, a problema je znalo biti i kod kombinacije 2 različita OS-a. tipa Windows XP i Windows Me/Home (što je ipak iza nas).
Kako ti reagira na null-ove i razne exceptione?
Negdje sam naletio na Table1.Active = True; i odmah potom Table1.Open što je zapravo ista metoda.
Malo uzimaš polja iz dataseta i puniš ih u vizualne kontrole, onda iz njih povlačiš polja i kalkuliraš pa vraćaš u dataset ili sl. Kalkulirati nad vrijednostima iz vizualnih kontrola je veliko žongliranje i preporučujem da se razne kalkulacije i krajnje validan podatak uvijek očitava iz dataseta, ako već nemaš neke svoje business klase. Znači iz kontrola preuzimaš podatak, validiraš ga i šalješ u dataset, podatke uvijek dohačaš iz dataseta, a obrade radiš nad datasetom. također i neki slijed logike. Jedno je događaj koji treba odraditi jer se promijenilo polje u datasetu, a drugo što je netko slučajno mišm kliknuo na formu ili izašao iz fokusa kontrole i sl.
Kao što kaže kolega Picard (Kapetane, jeste li to vi?, nisam vas čitao već 4 zvjezdane godine :) ) kad su u priči datasetovi i datasourcevi tada uz njih koristiš i dbaware kontrole tj. kontrole vezane na dataset. Potraži na netu helpove za D7, tamo je temeljno obrađena izrada DB aplikacija baš sa Paradoxom, mada iz nje treba izvući samo temelje i shvatiti koncepte. Inače, kad su u pitanju razni FishFact demoi u BDE ili s Accessom, oni su na žalost ujedno i loši primjeri kako programirati s bazama, no to ćeš vidjeti kasnije, dok savladaš taj početni korak.
Znači, sve je ovo viđeno i uobičajeno za početnički nivo. Nitko ne zna sve i nitko se nije učen rodio no zato imamo sposobnost učenja i usvajanja. Zato samo dalje, no uz čvrstu šaku nekoga iskusnog jer ćeš u spurotnom krenuti krivim putem i steći pogrešne navike, a njih se cijeli (programerski9 život teško riješiti.
Sretno!
God is real unless is declared as integer.
POS kasa dajte kritike i pohvale za program
