[Quote]Još jedan mali problem sa višestrukim formama.
Komanda za brzu pretragu po nekom polju u okviru subforme ne radi uvek:
Screen.PreviousControl.SetFocus
DoCmd.DoMenuItem acFormBar, acEditMenu, 10, , acMenuVer70[/quote]
Prva stvar koja treba da se predaje u skolama za programiranje jeste Zidareva teorema, koja glasi "The best code is no code at all", u prevodu "Najbolji kod je onaj koji ne postoji".
Znacenje - ako nesto moze da se resi bez koda, zasto pisati kod. Primer imas u samom Accesu. Sav database posao se svodi na forme i subforme, uglavnom povezane. U accesu je to ocas posla - navuces subformu na formu, i to je to, u vecini slucajeva. Pogledajmo druge jezika - .NET, VB, Java, web forme i ne pomijem, - da bi se to uradilo treba da se oznoj covek debelo i da dobije recimo 505 funkcionalnosti koju Access nudi.
Pretraga po kolonama se najbrze resava tako sto naucis klijenta da postivi kusor u kolonu i na desni klik pozove Accesov ugradjen metod za filtriranje vrednosti u koloni. U raznim verzijama se zove drugacije. U Acc 2012 se zove TextFilter, u drugim verzijama. Access nudi filtere za brojeve, text i datumska polja, mislim da ima i za Yes/No. Zakacio sam slike, za ilustraciju. Veruj mi, to prevazilazi sve sto i veoma iskusan i dobar programer moze da zamisli, i napravi. Takodje imas opciju "Filer By Selection". U starijim verzijama, Filetr By Selection je opcija na right click meniju. U novijim verzijama, mislim od 2007 naovamo, opcije koje su u vezi sa izabranim tekstom ili delom teksta u tekucoj celiji. Ovi filteri su jaci nego ugradjeni Find dialog box. Ako pukusas sam da napravis neku verziju Find dialog boksa, ima da se izmucis bez potreba za jako osiromaseno resenje.
Stoga, bez koda molim. Bas kao sto ZIdareva teorema zahteva.