Kontrolka ListView.

Mam taki problem. Zastanawiam się w jaki sposób połączyć dane z tabelki listview z inna tabela lub po prostu innymi danymi. Chodzi mi o to że do listview mogę wstawić w konstruktorze tylko stringi. A chcę dane, do rekordów w tabelce połączyć z innymi danymi których tam nie wstawię. Jak to zrobić? Czy istnieje coś takiego jak ukryty parametr elementu albo ogólnie ukryta kolumna?
Myslalem o czymś takim żeby stworzyć kolumnę "id" i za jej pomocą odwoływać się do tabeli, ale nie chcę pokazywać tego użytkownikowi. Co mogę zrobić?

Drugie pytanie, to jak można zrobić coś takiego, że jak włączę program to pojawiają się dane w okienkach które wprowadziłem za poprzednim razem, żeby nie trzeba było ich kilka razy wporwadzać. (mogę je zapisać w pliku ale chyba są też inne sposoby bo widziałem program który nie tworzy żadnego pliku)

kaszynek1 napisał(a)

Mam taki problem. Zastanawiam się w jaki sposób połączyć dane z tabelki listview z inna tabela lub po prostu innymi danymi. Chodzi mi o to że do listview mogę wstawić w konstruktorze tylko stringi. A chcę dane, do rekordów w tabelce połączyć z innymi danymi których tam nie wstawię. Jak to zrobić? Czy istnieje coś takiego jak ukryty parametr elementu albo ogólnie ukryta kolumna?

Nie bardzo rozumiem, ale generalnie obiekt każdej klasy posiada metodę ToString(), więc wszystko da się w stringa zamienić.
Wyraziłeś się niejasno, o jaką "inną tabelę" Ci chodzi? DataTable, inną kontrolkę WinForms, która wygląda jak tabela, czy po prostu zwykłą tablicę jakiegoś typu?

kaszynek1 napisał(a)

ale chyba są też inne sposoby bo widziałem program który nie tworzy żadnego pliku)

A nie było to czasem w salonie Ery?
(No, chyba że chcesz grzebać w rejestrze, co jest brzydkie i niepoprawne.)

Chodzi o to, że np mam tablicę elementów jakiejś klasy i na jej podstawie generuję listview i jeśli użytkownik kliknie jakiś element, to uruchamia się funkcja, która używa właściwości elementów z tej tablicy. W jaki sposób ona może kojarzyć odpowiedni element tej tablicy z nacisniętym elementem listview.

No dobra, czyli zostają mi tylko pliki?

A nie możesz uzyć właściwości .Tag, gdzie możesz wszystko wrzucać?

Bo taki np. ListBox i niektóre inne kontrolki posiadają DataSource, do którego można podpiąć jakąś kolekcję. A ListView czegoś takiego chyba nie ma.

somekind napisał(a)

kaszynek1 napisał(a)

ale chyba są też inne sposoby bo widziałem program który nie tworzy żadnego pliku)

A nie było to czasem w salonie Ery?
(No, chyba że chcesz grzebać w rejestrze, co jest brzydkie i niepoprawne.)

Ja bym tam nie demonizował rejestru. W końcu po coś istnieje cały wielgachny klucz SOFTWARE. Stwórz sobie tam swój klucz nazwany od nazwy programu i możesz śmiało z niego korzystać. Ale tylko jeśli jest tego niewiele, np. ustawienia użytkownika, ostatnio odwiedzane dokumenty (słowo "recent" jest w rejestrze bardzo popularne).

Jeśli potrzebujesz przechowywać większą ilość danych, zainwestuj w bazę. Plik mi osobiście podoba się najmniej. Ale czasem może być słuszniejszy od rejestru (patrz: przenośność)

Nigdy nie rozumiałem po co trzymać ustawienia programu i tego typu pierdoły w rejestrze, zamiast w plikach (rzecz jasna nie w katalogu aplikacji, ale np. w ApplicationData). Przecież to tylko niepotrzebne syfienie. Poza tym wydaje mi się trudniejsze do wykonania pod względem implementacyjnym.

somekind napisał(a)

Nigdy nie rozumiałem po co trzymać ustawienia programu i tego typu pierdoły w rejestrze, zamiast w plikach (rzecz jasna nie w katalogu aplikacji, ale np. w ApplicationData). Przecież to tylko niepotrzebne syfienie. Poza tym wydaje mi się trudniejsze do wykonania pod względem implementacyjnym.

Syfienie w rejestrze, czy syfienie w ApplicationData to syfienia tego samego rzędu. Implementacyjnie jest to łatwiejsze od trzymania danych w plikach, bo narzucony jest format klucz->wartość i nie musisz się zastanawiać nad sposobem serializacji. Wydaje mi się też, że odczyt z pliku i sparsowanie jest bardziej złożone od odczytu z rejestru, ale to kwestie marginalne.

Dlaczego używać? Odpowiedź jest taka sama jak na pytanie "dlaczego korzystać z gotowych mechanizmów?".

Hass napisał(a)

Wydaje mi się też, że odczyt z pliku i sparsowanie jest bardziej złożone od odczytu z rejestru, ale to kwestie marginalne.

Załóżmy, że mamy obiekt przechowujący dane konfiguracji. Serializacja do pliku - dwie linijki, deserializacja też dwie. Do rejestru łatwiej?

somekind napisał(a)

Hass napisał(a)

Wydaje mi się też, że odczyt z pliku i sparsowanie jest bardziej złożone od odczytu z rejestru, ale to kwestie marginalne.

Załóżmy, że mamy obiekt przechowujący dane konfiguracji. Serializacja do pliku - dwie linijki, deserializacja też dwie.

Musi to być obiekt łatwo serializowalny, np: Dictionary<> jest uciążliwy. A często konfiguracja to właśnie słownik parametr->wartość.

somekind napisał(a)

Do rejestru łatwiej?

Registry.GetValue(
	string keyName,
	string valueName,
	Object defaultValue
)
Registry.SetValue(
	string keyName,
	string valueName,
	Object value
)

No na pewno nie trudniej. Ale chodziło mi raczej o złożoność obliczeniową.

Hass napisał(a)

Musi to być obiekt łatwo serializowalny, np: Dictionary<> jest uciążliwy. A często konfiguracja to właśnie słownik parametr->wartość.

Też kiedyś miałem z tym problem. Rozwiązanie zajęło 5 sekund w Google ;P
To jeszcze zależy pewno jaka konfiguracja i czego, ja do swoich zastosowań zazwyczaj tworzę swoje klasy.
Poza tym jest chyba coś takiego jak ApplicationSettings, tam też dodaje się pary klucz-wartość, i chyba ląduje to w pliku, nie w rejestrze.

:] Ładnie to wygląda

W zasadzie na razie mam tylko użytkownika i hasło do zapamiętania, ponieważ w tym programie trzeba się logować, a nie chcę żeby za każdym razem trzeba było to wpisywać.

A czego podobnego do listview (chodzi mi o wygląd) można użyć (żeby miało takie fajne kolumny, można było zaimplementować sortowanie itd)?

DataGridView

Świetnie :] dzięki za pomoc