[c#] podświetlanie wiersza/y w DGV

Witam
Pytanie skierowane jest nie jak podświetlić i ustawić podświetlony wiersz na "widzialną pozycję", ale jak to powinno być zrobione poprawnie. Binding source ma parę metod np do wyszukiwania, filtrowania itd. Zastanawiam się czy nie ma już jakichś gotowych metod do zaznaczania (podświetlania) wierszy spełniających pewne kryteria. Przykładowo mam 5 wierszy po 4 pola (żeby było szybciej :) ) powiedzmy pole wiersza to poleA, poleB, ... , poleE. Użytkownik wskazuje, że mają być podświetlone wiersze, których poleB = 1000 i poleE < 5.

Rozwiązanie, które mi przychodzi do głowy to nałożyć filtr i wynik zapisać w jakiejś liście i usunąc ten filtr poczym iterując po liście rezultatu zaznaczać i zgrupować je np blisko siebie lub po prostu podświetlić wszystkie obiekty z listy rezultatu. Druga opcja to zapytanie linq na obiektach lub po prostu delegata. Myślę też czy gdy tych rekordów będzie np 800 000 000 czy nie powinienem tego Od razu upchnąc jakoś asynchronicznie, żeby nie mieć wtedy braku odpowiedzi. No i tu właśnie zrodziło się pytanie :). Która wersja jest bardziej poprawna ? Jest inna wersja lepsza ?

Chodzi mi tu tylko o to, że chcę nauczyć się pisać wedłóg jakichś wzorców, a nie na pałe rozwiązywać problemy. Przy okazji jeśli ktoś ma dobre strony ze wzorcami (które często są spotykane w praktyce) poparte przykładami w kodzie to poproszę. Ostatnio trochę mnie ten temat wciąga :)

Pozdrawiam

jesli masz sciagniete X elementow i chcesz zeby Y z nich bylo znaznaczone, ale zeby nadal wszystkie byly widoczne - niestety, nalozyc zaznaczenie musisz recznie.. a wiec sam musisz okreslic ktore wiersze maja byc zaznaczone i je pozaznaczac.. w tym celu:

• nie ruszaj oryginalnego grida, ani jego datasource, ani jego bindingsource. jakakolwiek zmiana w tych trzech rzeczach, zwlaszcza w BS, moze spowodowac przeladowanie danych na w gridzie, co jak pewnie zauwazyles, jesli wierszy jest duzo to moze to trwac i trwac.. w ogolnym przypadku duzej ilosci danych, chcesz jak najmniej przeladowan danych na GUI
• zeby to osiagnac sensowniej: utworz nowy bindingsource (BS2), jego datasource ustaw na stary BS, ustaw filtr w BS2 zgodnie z pomyslem. grid i jego BS caly czas zawieraja oryginal i nie zauwazyly zmiany, wciaz pokazuja full liste bez zadnego odswiezania, a w BS2 masz liste przefiltrowana
• czyli teraz, foreach na BS2 i per wiersz grid selection blah..
• pamietaj o Dispose na nieuzywanych bs'kach, poniewaz kazdy BS cache'uje dane! i to wszystkie dane ktorych dostarcza innym komponentow.. dlatego tez warto sie zastanowic czy rzeczywiscie chcesz uzywac bs jako kombajnu do latwego filtrowania jesli grozi Ci duzo kopiowania, nawet jesli to tylko referencje do obiektow.. 'brzydki' foreach po oryginalnym BS i reczne sprawdzanie warunku na pewno bedzie szybsze od niego!

jesli masz sciagniete X elementow i chcesz zeby Y z nich bylo znaznaczone, i zeby tylko one byly widoczne i one byly zaznaczone - po prostu ustaw filtr na BS, grid sie natychmiast ograniczy, wiec teraz tylko grid select all

BS to jedno podejscie, ale mozna tez uzywac innych modeli - np. DataSet/DataTable, DataView. DataSet to zbior tablic, DataTable to zbior wierszy, DataView to 'widok' tablic(y) - posortowany, odfiltrowany, etc.

i ostatnia rzecz.. w ogole, ladowanie 800mln (czy podobnej ilosc) wierszy do data grida mija sie z celem.. samo ich ladowanie wstepne bedzie trwac niesamowita ilosc czasu. w takich przypadkach, po porstu dane dzieli sie na porcje, "strony" np. po 500 wierszy i daje userowi mozliwosc "przewiajania". albo stosuje cokolwiek innego co te liczbe tymczasowo ograniczy..

//edit: porcje, strony - z ang. "paging"

no pokazywanie danych to już inna bajka, ale podzielenie na jakieś sensowne porcje to oczywiście racja, tylko ciekawe jak z podświetlaniem części wtedy nie widocznych (nie istniejących jeszcze właściwie w secie). No i zrodziło się nowe pytanie i wracam do testów :) Dziękować

najlepsze rozwiazanie jakie do tej pory widzialem bylo zrealizowane tak, ze wiersze zaznaczone byly zawsze wyswietlane (np. zawsze na gore, albo zawsze na dole), a 'nowosciagniete' dolepiane do nich, np:

• ma byc rowsPerPage wierszy per strona
• pager pamieta numerStrony
  2 zaznaczono lacznie X wierszy. kolekcja ('selectedRws') zaznaczonych (tylko!) wierszy jest trzymana po stronie gui (klienta) zawsze i nie wyparowuje przy zmianach stron.
  3 stronicowanie sciaga rowsPerPage+selectedRws.count wierszy poczawszy od numerStrony*rowsPerPage
  4 z wyniku zapytania usunac wiersze zaznaczone jesli jakies byly
  5 obciac wynik zapytania do pierwszych rowsPerPage
  6 do wyniku zapytania dolepic zaznaczone na koniec lub poczatek cale selectedRws
  7 wynik do grida, ewentualnie mozna juz numerStrony++

efekty:
pkt 3' - sciaganie X+selected.count gwarantuje, ze po usunieciu wierszy zaznaczonych zostanie tyle wierszy, zeby uzbierala sie wymagana ilosc
pkt 4' - usuwanie zaznaczonych (czyli tych ktore juz mamy) gwarantuje, ze nie pojawi sie ten sam wiersz na liscie dwa razy
pkt 6' - wygoda usera, zaznacozne wiersz enigdy nie znikaja, 'przylepiaja sie' do poczatku/konca listy

zrobilem to nieco inaczej, gdy user zaznacza aby wiersze z jego kryterium podswietlaly sie, to podlaczam listenera ktory wykonywany jest przy odrysowywaniu wierszy wtedy sprawdzam tylko komorke na ktora nalazyl kryterium np na kolumne 2 i sprawdzam czy warunek pokrywa sie. wtedy jest podswietlony. malo tego jesli bedzie trzeba to moge go dodac do selekcji :) a jesli wylacza swoj kryterium odswiezam wiersze bez sluchacza na ustawieniach domyslnych (odswiezam tylko widok, dane pobiera z juz wczytanych)

erm, okej.. pytales o podswietlanie 'czesci niewidocznych', wiec ja w poprzednim poscie po prostu opisywalem ogolne zachowanie sie page'owanych zbiorow z zaznaczeniami, a nie Twoj konkretny przypadek z auto-zaznaczaniem wg. kryterii :))