Search Forum Home   Visual FoxPro  Clase - VCX si PRG  Ajutor in OOP...  Ajutor in OOP    10/1/2010 9:10:07 AM Ovidiu Dobie 105 posts Ajutor in OOP  (N/A) Buna, Ţin să precizez de la bun început ca nu mai lucrat in stil OOP. Problema care o am acum stiu că ţine de acest stil. De exemplu, pt. a adăuga/modifica sterge un articol (de ex. disc frana, placute frana, bucse brat, amortizor) folosesc un form. Pentru a adauga o marca (de ex. Ford, Vw, Mercedes) sau un tip (Focus, Golf, A160) folosesc alte 2 formuri diferite. Toate cele 3 formuri au multe elemente in comun ... Se poate ca, de ex., toate aceste 3 "operatii" sa le fac folosindu-ma de un singur form? (...Asta ca sa imi usureze munca, daca descopar un bug sa nu merg sa modific codul in 3 formuri ci doar in unul singur...) Banuiesc cum ar trebui sa fac, ca pe fiecare am un grid care e legat de un view... controlsource-ul ar trebui schimbat dinamic in functie de ce aleg sa fac ... adica am in meniul aplicatiei, de ex., 3 submenus : Articole ... , Marci ... , Tipuri ... . si daca aleg articole sa deschid formul comun DO FORM Manager_Art_Marci_Tip si apoi in Init aleg controlsource-ul corespunzator. Si mai e ceva. De ex., la articole am "caracteristica" UM dar la Marci si Tipuri nu o am, asta ar fi greu de rezolvat? Sa folosesc proprietatea Visible pe form cu true daca am nevoie de o anume "caracteristica" si false daca nu am nevoie de ea? De ex. pe acel form comun as avea un buton Salvare, la care in Click sa fac un : DO CASE CASE alegere=1 &&  in meniu am ales articole .... CASE alegere=2 &&  in meniu am ales marci .... CASE alegere=3 &&  in meniu am ales tipuri .... ENDCASE Stiu ca inca gandirea mea este foarte "procedurala"  , de aceea v-am cerut ajutorul... Ovidiu Dobie  10/1/2010 11:43:14 AM Daniel Buduru 2335 posts Re: Ajutor in OOP  (N/A) Primul pas spre framework . Nu se practica utilizarea aceluiasi form cu schimbarea dinamica a surselor, dar se practica utilizarea unei clase in care sursele sa fie date in proprietati, si nu in cod. Ca idee, se creeaza o clasa - form sau container, eu am preferat container, poate fi pus oriunde, in form, in alt container, in pageframe, mai multe pe un form, in _screen  - care sa contina codul si controalele necesare. Pentru fiecare utilizare - articole, tipuri, marci, etc- se subclaseaza aceasta clasa si se particularizeaza prin setarea corespunzatoare a proprietatilor. Elementele necesare ar fi: - un container cu butoanele de adaugare/ salvare, modificare/revocare, stergere, duplicare, imprimare/vizualizare - o lista din care se alege inregistrarea ce se afiseaza/ editeaza. - un container in care se pun controalele necesare editarii inregistrarii parent, dar fara aceste controale - un grid pentru editarea inregistrarilor child - codul necesar pentru requery, salvare, revocare, etc., scris astfel incat sa nu contina nume proprii. Aici se for face enabled sau disabled controalele in functie de actiune: vizualizare sau editare. Plasarea lor in containere faciliteaza aceasta operatie. La subclasare, se adauga controalele necesare pentru editarea inregistrarii, derivate din clase proprii, nu din cele de baza. Controalele legate la cursor prin controlsource elimina necesitatea codului de genul "Replace tip with thisform.container1.text3.value in crsarticole" Daca este necesar, se populeaza gridul. Se utilizeaza combobox-uri pentru inlocuirea valorilor codificate - cum ar fi marca, idmarca. In combo se afiseaza in rowsource marca, idmarca, iar in controlsource crsaticole.idmarca. Combo se poate popula direct printr-un select, daca exista o tabela cu datele necesare. E de preferat ca in cod sa nu se refere nume de obiecte (altele decat cele continute deja in clasa), campuri, cursoare. Daca se realizeaza aceasta, nu va fi necesar sa se modifice codul in functie de obiectele din form. Se poate pune o metoda, de ex BeforeSave, in care sa se scrie codul necesar pentru verificarea datelor introduse, eventuale corelari si completari, apelata inainte de salvare, care sa permita continuarea operatiei doar daca inregistrarea e valida. Daca s-a realizat corespunzator aceasta clasa - precum si clasele folosite pentru controale, subclasarea nu ar trebui sa aiba nevoie de cod suplimentar. Utilizarea unui cursoradapter in locul view-ului permite o flexibilitate si mai mare. Se poate crea cate o clasa CA pentru fiecare view, si se instantiaza cand este necesar. Comoda ar fi utilizarea unui BussinessObject, care ar instantia CA, s-ar ocupa de aducerea datelor, validare, salvare. Aici ar fi mai mult de spus ... Cum ziceam, este primul pas spre framework. Pasul urmator este crearea de buildere care sa aduca singure controalele nevesare, sa le plaseze, sa le completeze proprietatile,.... Nu este neaparat necesar acest pas. Dar primul, crearea unor clase proprii, cu codul necesar, este. Si usureaza enorm munca. Daniel Buduru  10/1/2010 1:06:36 PM Ovidiu Dobie 105 posts Re: Ajutor in OOP  (N/A) Multumesc pt. raspunsul prompt... Banuiam ca spre Framework trebuie sa ma indrept... dar pentru ca nu am mai lucrat OOP nici macar nu aveam ideea de unde sa incep... Pe baza celor scrise de tine am de unde porni si am ce studia multa vreme de acum incolo... BusinessObject este chiar un termen nou pentru mine, voi cauta informatii sa vad despre ce e vorba... Pana sa ajung acolo, m-as bucura sa-mi reuseasca prima clasa facuta de mine... imi pare rau ca a trecut repede vremea si doar acum ma gandesc serios la trecerea spre OOP ... Despre cursoradapter am mai citit si stiu ca are avantaje fata de view-uri .. dar eu am facut pasi marunti .. .de la niste tabele temporare populate cu SCAN si APPEND BLANK am trecut la views ...si a fost foarte util pentru mine si cerintele ce le primesc (care bineinteles nu sunt foarte mari ...) Pe mine m-ai cam pierdut pe la al treilea paragraf... de aceea, dupa ce studiez treaba, daca voi avea nelamuriri voi reveni pe acest thread cu intrebari... Deocamdata, multumesc mult de tot pt. ajutor! Ovidiu Dobie  Page 1 of 1   Visual FoxPro  Clase - VCX si PRG  Ajutor in OOP... Flat View Tree View Oldest To Newest Newest To Oldest