[ rambo @ 13.04.2009. 11:17 ] @
Dakle, imam sledeći problem:

Na jednoj formi imam ListView (VirtualListView ili običan ListView, nije bitno) koji mi služi za prikazivanje podataka iz jednog Query-ja. Pored prikaza, potrebno je da se ti podaci menjaju "na licu mesta". Query može da vrati 0, jedan ili više zapisa.

Da bi korisnik mogao te podatke da menja, imam par scenarija.

1. in-place editor u samom gridu,
2. panel iznad ListView-a koji prikazuje podatke iz selektovanog reda i omogućava njihovo menjanje,
3. nova forma koja prikazuje podatke iz selektovanog reda i dozvoljava njihovo menjanje.

Ja bih najradije napravio prvu varijantu, ali postoji jedan problem. Jedan od podataka treba da se menja preko ComboBox-a, tj. potrebno je da korisnik iz ComboBox-a izabere željeni item (itemi se popunjavaju iz druge tabele). Tako nešto mogu da uradim sa VirtualStringTree koristeći EditLink, ali mi je malo prekomplikovano za implementaciju (napravio sam test projekat, stvar radi, ali ne baš kako sam zamislio). Zanima me dali je moguće napraviti ovako nešto koristeći neku drgu komponentu tipa ListView (u obzir dolaze JVCL ili bilo šta freeware). Pored ComboBox-a, bilo bi poželjno da takav grid podržava i CheckBox kolone (znači ne CheckBox za svaki red, već više kolona kao CheckBox (tip podatka Boolean)).

Druga i treća varijanta nisu problem, ali bi mi zbog konzistentnosti UI cele aplikacije više odgovarala prva.
[ Boris B. @ 13.04.2009. 11:47 ] @
Po mom misljenju in-place grid editore treba izbegavati za sve osim za najosnovnije tabele. Uzmimo za primer tipicnu aplikaciju za robno knjigovodstvo. U toj aplikaciji imas npr. tabele artikala, grupe artikala, proizvodjace, klijente, racune, predracune, itd. Prvo odlucis koji entiteti su nosioci arhitekture aplikacije i koji su pomocni entiteti. U ovom primeru samostalni entiteti bi bili Racun, Predracun, Klient, Artikal, pomocni bi bili Proizvodjaci i grupe artikala. Pomocne entitete mozes slobodno da strpas u in-place gridove jer se unose jako retko i bitni su samo za konktretan entitet, npr. grupa artikla i proizvodjac samo opisuje Artikal. Glavni entiteti bi trebalo da imaju posvecen editor u vidu svoje forme ili jos bolje frame-a za editovanje. Ako napravis editor Racuna u vidu frame-a koji prima PK iz baze kao parametar, taj editor mozes da pozivas sa bilo kog mesta iz tvoje aplikacije i uvek ce izgledati isto i korisniku poznato, znaci konzistentno. Ovim omogucavas korisniku drill-down sitem dolazenja do podatka, npr ListaRacuna->Racun->Artikal ili NeplaceniRacuni->Racun->Klijent ili bilo sta drugo, poenta je da imas editore za svaki samostalni entitet, pises ih kao samostalne frame-ove i posle samo gradis put za dolazak do konkretnog podatka. Druga stvar, gridovi najcesce predstavljaju pregled necega i ti pregledi ne bi trebalo da sadrze kolone za bas svaki podatak. Ako kasnije siris aplikaciju, a skoro sigurno hoces, morao bi u svakom gridu gde se pominje racun da dodajes/menjas polja i pises logiku za in-place editore.
[ rambo @ 13.04.2009. 12:47 ] @
Borise, hvala na odgovoru, ali si promašio.

U pitanju je jednostavan dataset, ali se ne koriste Data-aware komponente. U Gridu ima svega 5 kolona od kojih je samo jedna "eksterna", tj. samo se u jednoj nalazi ComboBox koji sadrži stavke iz druge tabele.

Nije problem to, već dali i kako implementirati editovanje tih podataka pomoću in-place editora. Mislim da ću se ipak zadržati na tradicionalnom pristupu, tj. primeniću drugi ili treći metod.

VirtualTreeView je jako moćan i projektovan je tako da bude proširiv do besvesti, ali je meni za sada taj pristup malo komplikovan i oduzeo bi mi previše vremena.

Kada budem uradio ovo, postovaću novo mišljenje, pa će možda poslužiti još nekome kao savet.
[ Boris B. @ 13.04.2009. 15:28 ] @
>"promašio"
LOL

Na osnovu tri moguca scenarija koje si naveo razumeo sam tvoje pitanje kao "da li da koristim inplace grid editore ili dedicated kontole za izmenu podataka" i shodno tome dao odgovor za opsti slucaj, jbg