Model de aplicație bazat pe evenimente
Să construim ce definește modelul de aplicație bazat pe eveniment în FoxPro. Programarea unei aplicații bazate pe evenimente determină în principal faptul că puteți avea mai multe ecrane pe ecranul calculatorului și atunci când comutați între ele folosind mouse-ul, este activat codul care controlează funcționarea fiecărui ecran. Dacă ecranul este închis de alții, puteți utiliza meniul pentru a-l apela. Ecranul există până când utilizatorul îl închide. Aplicația se așteaptă la un "eveniment" (selectarea opțiunii de meniu, clic pe mouse), aceasta dă numele termenului "eveniment-condus".
Spre deosebire de Visual Basic sau Clipper 5.0, FoxPro nu intră în starea de așteptare a evenimentului în sine. Trebuie să creați această stare. Aceasta se face folosind comanda READ.
READ se așteaptă să introducă date în câmpul creat de comanda @. GET. așa cum a fost întotdeauna, dar, în plus, echipa este gata să reacționeze la orice eveniment care încearcă să o completeze. Este pentru procesarea unui astfel de eveniment o clauză valabilă.
Dacă folosim funcția READ VALID construct func (). apoi READ rămâne activ până când func () returnează .T. (Adevărat). Până atunci, aplicația poate arunca controlul ca un volei. Cu toate acestea, simplitatea se termină. Din acest moment, situația începe să se complică.
Dacă selectați opțiunea de meniu, FoxPro execută comanda sau procedura asociate. Cu toate acestea, nu există nicio garanție că oricare dintre acțiunile dvs. va declanșa logica asociată cu clauza VALID. atunci când comanda READ. Se pare că trebuie să ai grijă și de asta. Când faceți clic pe o fereastră care nu este în partea de sus, trebuie să găsiți și să rulați modulul .SPR corespunzător. FoxPro nu oferă un mecanism care să facă acest lucru în mod automat. Cu toate acestea, există mai multe puncte în care puteți interveni în cursul natural al evenimentelor și le puteți trimite la un canal convenabil pentru dvs.
Unul dintre aceste puncte este furnizat de clauza READ DEACTIVATE în modulul .SPR. Generatorul de ecran FoxPro aprovizionează fiecare ecran sau set de ecrane cu comanda READ. la care puteți atașa blocuri de cod. Aceste blocuri sunt asociate cu propoziții care pot fi folosite împreună cu READ: SHOW, SETUP, CLEANUP, ACTIVATE și DEACTIVATE. Aceste propuneri constituie prima parte a programului cheie pentru programarea aplicațiilor bazate pe eveniment în FoxPro, READ VALID este a doua parte, dar vom vorbi despre asta mai târziu.
Când GENSCRN execută generarea de coduri, Codul de instalare este plasat chiar la începutul programului care este creat, iar blocul de închidere (Codul de curățare) ajunge la sfârșit. În mijlocul unui fișier SPR, generatorul plasează comenzi GET. urmat de READ. READ poate avea până la trei propoziții, fiecare dintre acestea putând corespunde unui bloc de cod sau unui apel de procedură.
Codul asociat cu clauza SHOW. este executată de fiecare dată când se execută comanda SHOW GETS. astfel încât este necesar să inserați o logică care actualizează conținutul ecranului curent. Dacă nu aveți nimic de actualizat, cu excepția conținutului câmpurilor GET. Lăsați această propoziție goală. Cu toate acestea, pentru aplicațiile bazate pe evenimente, codul asociat cu clauzele ACTIVATE și DEACTIVATE. devine extrem de important.
Codul asociat cu ACTIVATE. este executat de fiecare dată când încercați să aduceți ecranul corespunzător în sus, fă-l activ. În cazul în care programul dvs. are comenzi pentru a naviga prin înregistrări, este posibil să introduceți cod care vă garantează că mergeți la spațiul de lucru dorit pentru acest ecran, cum ar fi SELECT <имя рабочей области>. Aceasta este cea mai frecventă utilizare a ACTIVATE și adesea singura.
Dimpotrivă, DEACTIVATE joacă un rol extrem de important în crearea de aplicații bazate pe evenimente. Încercați acest lucru: porniți FoxPro, definiți o pereche de ferestre și activați ambele. Acum faceți alternativ clic pe fiecare fereastră și deschideți meniul Window (Alt + W), vedeți ce se face cu ordinea enumerării numelor ferestrelor. Veți vedea că ordinul se schimbă. Aceasta este abordarea construirii de aplicații bazate pe evenimente.
În multe aplicații bazate pe evenimente, veți găsi o funcție care citește o listă cu nume de ferestre pentru a determina ultimul element. De ce? Nu se poate utiliza funcția WONTOP (). Poți, dacă nu folosești seturi de ecran. Acum, o practică comună de a utiliza o singură fereastră cu controale pentru a comuta între conturi, comutarea între modurile, și așa mai departe. N. Pentru această funcționalitate aveți nevoie pentru a crea un set de ecrane, format din caseta de control și a ferestrelor, apoi în codul asociat cu oferta activa . asigurați-vă că adăugați următoarele rânduri:
Activați Windows (numele ferestrei)
ACTIVEAZA CONTROLUL FERESTREI
Ca urmare, se pare că fereastra dvs. nu este situată în partea de sus, este penultima. (În practică, ați citit lista de ferestre de sus în jos, păstrând numele ferestrelor, cu excepția numelui Control).
În mod similar, nu există nicio modalitate frumoasă de a determina fereastra care tocmai a fost închisă. Prin urmare, recepția este comună atunci când numele ferestrei care urmează să fie închisă este trecut ca parametru prin codul din READ DEACTIVATE.
Cum se face această programare pe bază de evenimente? În primul rând, presupunem că până când pe ecran apare cel puțin o fereastră activă, utilizatorul va deschide ferestrele, selectându-le din meniu. Utilizați comanda:
Pe bara de selecție 1 a bazei de date DO nextprog WITH 'Contact.Spr'
Programul inclus include funcția NextProg. prezentate în Lista 14-1 și la sfârșitul listei 14-3.
Aceasta înseamnă că "dacă în prezent nu există nicio procedură activă, executați cea selectată din meniu, altfel vom modifica valoarea variabilei NextProgram și vom emite o CLEAR READ".
Programul NextProgram este numit "coada de evenimente". În aplicații complexe, precum biroul lui Tom Rettig. coada evenimentelor poate fi multi-nivel, poate fi necesar să efectuați mai multe acțiuni obligatorii la finalizarea unui anumit mod și aici trebuie să creați un mecanism pentru determinarea acțiunilor în funcție de situația dvs. Programarea bazată pe evenimente nu este pentru cei slabi. În exemplul nostru simplu, coada este, de asemenea, necomplicată.
De ce citiți clar. De ce nu doar DO (NewProgram). Motivul este că trebuie să curățați sarcina curentă și CLEAR READ vă obligă să executați clauza READ VALID. Această abordare vă permite să direcționați toate procedurile de modificare a ecranului printr-un singur canal.
Procedură care rulează în secțiunea CITEȘTE VALIDĂ. se numește Evenimente. Acesta este prezentat în Lista 14-2.
Pot exista trei evenimente reciproc exclusive:
1) aplicația este terminată - utilizatorul a selectat opțiunea Ieșire din meniu;
2) utilizatorul a ales un alt mod de operare în meniu;
3) utilizatorul a dat clic pe mouse-ul de pe fereastră.
În exemplul nostru, numele de ferestre care se termină cu o cifră sunt utilizate, am făcut acest lucru pentru a simplifica codul în CITEȘTE VALIDĂ. Dacă fereastra are numele multiwin. apoi MultiRead include un număr de fereastră care poate fi utilizat pentru a restabili numele ferestrei. Acest lucru facilitează citirea codului. În programele dvs. nu pot fi ferestre conexe, dar dacă sunt, atunci metoda mea funcționează destul de bine.
Iată cum funcționează aplicația bazată pe evenimente în FoxPro. În Visual FoxPro, este posibil să nu fiți nevoiți să vă confruntați cu toate aceste dificultăți. Între timp, acest lucru se face exact așa.
Variații pe aceeași temă
Am dezvoltat mai multe variante ale abordării de creare a aplicațiilor bazate pe evenimente și cred că acestea se vor dovedi a fi interesante și utile. Aceste opțiuni sunt descrise în secțiunile următoare.
CLEAR READ are ca rezultat executarea silită a codului asociat cu CITEȘTE VALID în fundalul READ. De ce să nu folosiți același nume de fereastră în mai multe fișiere .SPR și să apelați diferite programe fără a crea o fereastră nouă? Am încercat și în câteva minute am primit un model de lucru.
Exemplul include trei fișiere Contact1, Contact2, Contact3. Fereastra are numele Contact în toate cele trei ecrane. Amintiți-vă că GenScrn creează un cod ca acesta:
DACĂ WISBLE ("contact")
ACTIVEAZAȚI contactul WINDOW SAME
ELSE
Activați contactul WINDOW NOSHOW
ENDIF
. un cod.
DACĂ NU WISIBLE ("contact")
Activați contactul WINDOW
ENDIF
Pentru a apela următoarea "pagină", procedați astfel:
NextProgram = "Contact3.Spr"
CITIȚI CLEAR
În exemplul nostru, GET trebuie să adopte anumite poziții pentru a evita suprapunerea. Dacă n-aș fi făcut asta, aș fi făcut-o:
DACĂ WONTOP () = "CONTACT"
ACTIVEAZAȚI contactul WINDOW SAME
@ 10.1 CLEARĂ LA 15.57
ENDIF
O altă abordare găsiți dacă vă uitați la codul care organizează ieșirea mai multor ecrane atunci când utilizatorul selectează opțiunea Despre din meniul principal.
Una dintre metodele de susținere a fișierelor părinte-copil implică redimensionarea unui tablou cu date din fișierele copil și afișarea rezultatelor în cele mai puternice dintre noile obiecte GET - o listă derulantă. Matricea este modificată în procedura asociată cu clauza SHOW din ecranul părinte.
PENTRU i = 1 TO nActivCnt
aActivitatea [i, 6] = DTOC (aActivitatea [i, 2]) + "| +;
aActivitatea [i, 3] + "|" +;
aActivitatea [i, 4] + "|" +;
aActivitatea [i, 5]
ENDFOR
(Puteți obține același lucru cu o comandă SQL, care poate fi și mai rapidă):
SELECT ACTIVITY.AID, ACTIVITY.DATE, ACTIVITY.TIME, ACTIVITY.TYPE;
ACTIVITY.CONTACT, DTOC (ACTIVITY.DATE) + ' '+ ACTIVITY.TIME +' +;
ACTIVITY.TYPE + '| '+ ACTIVITY.CONTACT;
DE ACTIVITATE, CONTACT;
WHERE CONTACT.ID = ACTIVITY.ID;
În arabilitate
Pentru o listă de defilare, atunci când creați ecranul, trebuie să marcați opțiunea Primul element și să introduceți o expresie (expresie) 6 (al șaselea element al matricei recepționate ar trebui să fie listat). Apoi puteți selecta un element din listă pentru a găsi intrarea corespunzătoare din fișierul copil.
Codul din clauza VALID arata astfel:
DACĂ NACTIVAT> 0
Selectează activitatea
LOCAȚI PENTRU ajutor = Activitate [nActivitate, 1]
ENDIF
UrmătorulActivitate = .T.
NextProgram = "activity.spr"
CITIȚI CLEAR
În acest caz, putem găsi o înregistrare copil, dacă există, sau adăugați una nouă.
FoxPro 2.0 are mai multe directive pentru generatorul - comenzi care controlează generarea de coduri. În versiunea 2.5, au fost adăugate alte câteva directive, unele dintre ele foarte utile.
Evenimente-driven FoxPro aplicații au avut întotdeauna o cantitate imensă de cod repetitive. Partea de instalare și de închidere a programelor de creare a ecranului a fost, dacă nu complet identică, cel puțin foarte asemănătoare. Versiunea 2.5 oferă o nouă directivă care reduce riscul de eroare atunci când introduceți în mod repetat același cod sau când îl copiați - aceasta este direcția #INSERT.
Noua directivă este un instrument minunat. Dacă programul de instalare, închidere, verificare și alte secțiuni ale programelor au o funcționalitate comună, trebuie doar să scrieți codul o singură dată. În exemplul Listing 14-3, sugerez mai multe proceduri standard setup.gen (procedură de configurare), show.gen (procedura de actualizare a variabilelor pe ecran), precum și mai multe secțiuni specifice de aplicație, dar repetitive - contact.set (partea de instalare a codului) și contact.cln (ultima parte a codului). Dacă trebuie să modificați funcționarea aplicației, trebuie doar să efectuați corecturi la mai multe module standard.
Rețineți că modificarea codului în procedurile standard nu va determina managerul de proiect să regenereze codul pentru a crea ecrane. După efectuarea modificărilor, trebuie să reasamblați proiectul cu opțiunea [] Build [All] bifată. De asemenea, puteți șterge fișierele .SPR pe care modulele modificate ar trebui să le acceseze, dar este ușor să le uitați.
Ți-am oferit mai multe abordări. Sunt sigur că veți găsi multe alte soluții.