Search  
Friday, May 25, 2012 ..:: Forum ::.. Register  Login
 Forum Minimize
Pentru a putea posta mesaje trebuie să vă înregistraţi.
Notă: Mesajele cu conţinut jignitor sau ilegal (inclusiv cereri de soft piratat) nu sunt acceptate şi vor fi şterse imediat .

Pentru a primi raspunsuri rapide si corecte, scrieti in mesaj ce intentionati sa faceti, ce mesaj de eroare primiti, in ce context si in urma caror actiuni. De asemenea, mentionati versiunea de FoxPro in care lucrati!
Dacă nu specificați versiunea, se consideră VFP 9.0 SP2.

SearchForum Home
  Visual FoxPro  Clase - VCX si PRG  Dilema - stare ...
 Dilema - stare controale in mod edit/view
 
 9/4/2006 3:59:27 PM
User is offlineDorin Vasilescu
1366 posts
1st




Dilema - stare controale in mod edit/view
 (Romania)
Salutare
Vreau sa fac o modificare la logica de activare/dezactivare(sau read only) a controalelor pe care o am (acum oarecum simplista, in Refresh) in momentul cand formul este in modurile add,edit sau view

Vreau sa adaug la clasele de baza 4 proprietati:
formMode : care poate lua valorile "add","edit" sau "view" sau "A","E","V"
onAddStates : care poate fi ceva de genul "Readonly=.F.,Enabled=.T.,AlowCellSelection=.T."
onEditStates, onViewStates, la fel ca precedenta

Cand un form este pornit cu proprietate mode='edit', ar trebui sa se treaca prin toate controalele si sa se modice proprietatile specificate cu valorile respective. Controlul face parsing in Init si desface in bucatele acea proprietate intr-un array sau colectie, folosit ulterior la atribuire.

Am ajuns la 3 variante si nu stiu care ar fi cea mai potrivita
1. Modificare mode_Assign la form , sa dea un SetAll(...) la toate controalele. Daca un control este de tip container, sa aiba si acesta un SetAll(...) in Assign.
2. Parcurgere recursiva la toate controalele in codul Assign al form-ului (nu mai trebuie formMode la controale)
3. O clasa care face BINDEVENT() pe proprieatea formului si executa parcurgerea controalelor similar cu mai sus.

Ce ziceti? Sau ma complic?

Varianta 1 ar avea sanse sa fie mai rapida, pentru ca parcurgerea controalelor se face in cod nativ.

 9/4/2006 4:43:28 PM
User is offlineaflorin
840 posts
1st


Re: Dilema - stare controale in mod edit/view
 (Romania)
Eu as avea doua idei:

pe linga container, si controlul de tip PageFrame trebuie parcurs recursiv
as inlocui onAddStates= "Readonly=.F.,Enabled=.T.,AlowCellSelection=.T." cu un numar de trei cifre in care fiecare cifra reprezinta .t./.f. pentru cele trei proprietati. Ma gindesc ca lucrul cu numere este mai rapid decit parsarea stringului si (probabil) macrosubstitutia.

Florin Aparaschivei - Iasi
 9/4/2006 6:41:29 PM
User is offlinevlatis
122 posts
5th


Re: Dilema - stare controale in mod edit/view
 (N/A)
imho, in Refresh, asa cum inteleg ca-s acuma, cred ca-i locul cel mai potrivit.
De ce spun asta? VFP-ul gestioneaza corect refresh-ul la nivelul form-ului, am scapat de beleaua de a parcurge intr-un mod oarecare controalele pe care le contine si al le modifica proprietatile. In al doilea rand, am posibilitatea de a `regla mai fin` modul de prezentare a controalelor in cele trei stari (A,E,V) decat prin SetAll ( ex: ce se potriveste ca setari pentru un textbox in starea V nu se potriveste pentru un combobox, editbox sau checkbox)
 9/4/2006 8:20:41 PM
User is offlineDorin Vasilescu
1366 posts
1st




Re: Dilema - stare controale in mod edit/view
 (N/A)
 aflorin27 wrote
Eu as avea doua idei:

pe linga container, si controlul de tip PageFrame trebuie parcurs recursiv
as inlocui onAddStates= "Readonly=.F.,Enabled=.T.,AlowCellSelection=.T." cu un numar de trei cifre in care fiecare cifra reprezinta .t./.f. pentru cele trei proprietati. Ma gindesc ca lucrul cu numere este mai rapid decit parsarea stringului si (probabil) macrosubstitutia.


Eu m-am gandit la toate containerele sa fie parcurse recursiv sau doar atribuita starea formului.

"Readonly=.F.,Enabled=.T.,AlowCellSelection=.T." erau arbitrar alese.
Eu am mers cu gandul pana la a putea specifica si "Column1.CurrentControl=[ctrlPtView]", etc... (am avut cazuri, dar am pus cod explicit)
Parsingul am de gand sa-l codez intr-o metoda sau chiar generic, prin referinta, o singura data, in Init().



 9/4/2006 8:47:22 PM
User is offlineDorin Vasilescu
1366 posts
1st




Re: Dilema - stare controale in mod edit/view
 (N/A)
 vlatis wrote
imho, in Refresh, asa cum inteleg ca-s acuma, cred ca-i locul cel mai potrivit.
De ce spun asta? VFP-ul gestioneaza corect refresh-ul la nivelul form-ului, am scapat de beleaua de a parcurge intr-un mod oarecare controalele pe care le contine si al le modifica proprietatile.


Ai dreptate. Am vrut sa renunt la Refresh din cauza ca nu a fost de ajuns, mai trebuiau ajustari in cod, depinzand de context (m-am limitat la Enabled, ReadOnly, restul in cod). Dar poate nu am fost eu destul de insistent :). Problema e ca trebuie Refresh la toate containerele, altfel.... Si cam tot acolo ajungi.

O sa fac niste benchmark-uri, pana la urma , cu multe obiecte, sa vad ce iese.

Ma atrage ideea unui obiect extern, care sa-si faca treaba independent, doar il pui pe form si face tot.

Va tin la curent, voi posta si un exemplu.
 9/4/2006 8:51:09 PM
User is offlinevlatis
122 posts
5th


Re: Dilema - stare controale in mod edit/view
 (N/A)
 Dorin Vasilescu wrote

Parsingul am de gand sa-l codez (...) sau chiar generic, prin referinta, o singura data, in Init().



...asta ar insemna sa reinstantiezi formul la fiecare comutare intre moduri(AEV)?

 9/4/2006 9:07:29 PM
User is offlinevlatis
122 posts
5th


Re: Dilema - stare controale in mod edit/view
 (N/A)
 Dorin Vasilescu wrote

Ma atrage ideea unui obiect extern, care sa-si faca treaba independent, doar il pui pe form si face tot.



Acest obiect ar trebui sa parcurga intregul arbore ce descrie continutul formului/formsetului si pentru fiecare tip de control cunoscut sa-i modifice proprietatile in concordanta cu tipul controlului si starea in care e pus formul/formsetul. Ce faci in cazul in care ai un control nou, definit de tine sau de altcineva (chiar daca acesta este doar un container care contine controale de baza) iar acesta trebuie sa aiba `personalitate`?
 9/4/2006 9:45:45 PM
User is offlineDorin Vasilescu
1366 posts
1st




Re: Dilema - stare controale in mod edit/view
 (N/A)
Il las in pace. Inseamna ca asta am vrut si m-am ocupat de el individual . Caut doar obiecte care au setate proprietatile de interes.



 9/4/2006 9:51:08 PM
User is offlineDorin Vasilescu
1366 posts
1st




Re: Dilema - stare controale in mod edit/view
 (N/A)
 vlatis wrote
 Dorin Vasilescu wrote

Parsingul am de gand sa-l codez (...) sau chiar generic, prin referinta, o singura data, in Init().
...asta ar insemna sa reinstantiezi formul la fiecare comutare intre moduri(AEV)?



A, nu. Ma gandeam la Init-ul obiectului si la o proprietate care sa semnaleze ca s-a efectuat parsingul. Asta inseamna ca exista un array/colectie cu aProp[1,1]='Refresh' , aProp[1,2]=.T. sau oCollection.Item("Refresh") = .T. (nu m-am hotarat inca)

 9/4/2006 10:19:44 PM
User is offlinevlatis
122 posts
5th


Re: Dilema - stare controale in mod edit/view
 (N/A)
Pai tot la reinstantierea formului ajungi pentru o functionare acceptabila...La Init o ia `de jos in sus`...(poate n-am inteles 100%, dar pentru a asigura functionalitatea dorita prin init nu ai cum face decat prin reinstantierea formului)
 9/4/2006 10:25:00 PM
User is offlineDorin Vasilescu
1366 posts
1st




Re: Dilema - stare controale in mod edit/view
 (N/A)
sau _Assign()
 9/4/2006 10:39:53 PM
User is offlinevlatis
122 posts
5th


Re: Dilema - stare controale in mod edit/view
 (N/A)
K! (...dar era vorba de init...)

 9/5/2006 11:57:25 PM
User is offlineDorin Vasilescu
1366 posts
1st




Re: Dilema - stare controale in mod edit/view
 (N/A)
Am incropit acu' seara ceva...

Am creat un obiect de tip custom, care parcurge, la "cerere" , toate obiectele dintr-un form (si recursiv in toate subcontainere acestuia)
Urmareste daca controlul are setate proprietatile onEditStates, onAddStates, onViewStates, face parsing pe acestea, le desface in bucatele si le memoreaza in colectii. Ulterior, modifica proprietatile in conformitate cu proprietatea formmode , la cerere

Proprietati:
refreshControl=.F., daca este .T., da si un refresh la control dupa ce-l "viziteaza"

Metode:

Parse( oObj )
: face ce am zis mai sus, referinta controloului este transmisa in oObj. De notat ca parseChar=| (shift \ ). Este executat de ctrlIterator()

ctrlIterator(oCntRef, cAction, cFormState):
trece prin toate controalele, recusiv la containere. Parametri: ocntRef : referinta form/container, cAction :"parse", "modify", cFormstate: "add","view","edit". Executa Parse() si/sau Adjust() pentru fiecare

Adjust
(oObj, oPropsCollection) = modifica proprietatile oObj conform valorilor din oPropsCollection)

hostModeHandler() : pentru BINDEVENT() pe form.formmode

Ce am observat:
Timpul de executie fara Refresh este foarte scurt la monstrul ala de form din exemplu.
Daca se face refresh, fara cod, timpul creste de 10 ori, aprox.
Presupun ca, daca ar exista cod xbase in fiecare Refresh() in fiecare control, ar fi mult mai mult timp.
Cred ca abordarea de a crea un obiect extern este cea mai buna ( sincer, nici nu mai imi vine sa incerc altceva )

As fi curios de rezultate cu refresh() care sa faca ce face obiectul, dar nu pe timpul meu :)).

Sugestii, buguri?


 9/6/2006 11:00:28 AM
User is offlinevlatis
122 posts
5th


Re: Dilema - stare controale in mod edit/view
 (Romania)

Experienta ( 'o ceva' pe care o obtii, depasind rutina, numai atunci cand nu mai ai nevoie de ea ) si-a spus cuvantul. Jos palaria! Sunt impresionat!

Am incercat 's-o pun pe burta' si deocamdata n-am reusit ... mai insist (apropo de buguri)

 9/6/2006 11:44:51 AM
User is offlineDorin Vasilescu
1366 posts
1st




Re: Dilema - stare controale in mod edit/view
 (Romania)
Eu a reusit, cand facea parsing dupa virgula
De aia l-am schimbat
  Visual FoxPro  Clase - VCX si PRG  Dilema - stare ...

Search  Forum Home         

 Google Ads Minimize

    

Copyright 2002-2010 Profox   Terms Of Use  Privacy Statement