ListView WPF pobieranie wszystkich elementów

Witam.

W jaki sposób można pobrać wszystkie elementy które są w ListView?
Nie chcę przy tym rzutować elementów na dane obiekty, bo to ma być metoda uniwersalna do wszystkich ListView w aplikacji (chodzi o eksport do pliku).
Do ListView elementy wrzucam przez ItemsSource.

Kod który mam teraz nie jest w pełni poprawny, ponieważ eksportuje mi tylko te elementy które są aktualnie widoczne (tj. jeżeli mamy 300 elementów, a na ekranie widać tylko 10, to wyeksportowane będą tylko te widoczne).

StringBuilder sb = new StringBuilder();
                    int columncount = ((GridView)lv.View).Columns.Count;
                    foreach (GridViewColumn h in ((GridView)lv.View).Columns)
                    {
                        sb.Append("\""+h.Header.ToString() + "\";");
                    }
                    sb.AppendLine();
                    for (int i = 0; i < lv.Items.Count; i++)
                    {
                            ListViewItem lvi = lv.ItemContainerGenerator.ContainerFromIndex(i) as ListViewItem;
//Tutaj dla niewidocznych elementów w lvi mam null
                            if (lvi != null)
                            {
                                GridViewRowPresenter gvp = FindVisualChild<GridViewRowPresenter>(lvi);
                                for (int j = 0; j < columncount; j++)
                                {
                                        DependencyObject col = VisualTreeHelper.GetChild(gvp, j);
                                        TextBlock tb = col as TextBlock;
                                        sb.Append("\""+tb.Text + "\";");
                                }
                            }
                        sb.AppendLine();
                    }
                    File.WriteAllText(saveFileDialog.FileName, sb.ToString());

ListView jest wirtualizowany dlatego pobierasz tylko te elementy, które widzisz. Prawidłowym rozwiązaniem jest wykorzystanie MVVM i zbindowanie ListView.Items do kolekcji obiektów tj. ObservableCollection<T>.
Jeżeli chcesz pozostać przy rozwiązaniu, które posiadasz to możesz wirtualizację wyłączyć:

<ListView VirtualizingStackPanel.IsVirtualizing="False"/>

Ze względu na to, że ma to być opcja uniwersalna dla wszystkich ListView to ja chyba podszedłbym do tego w taki sposób, że bym bindował ObservableCollection<object>, oczywiście w ObservableCollection byłyby trzymane konkretne typy, przy eksporcie użyłbym reflection i pobierał np. wszystkie property, które mają publiczny getter. Na pewno można to zrobić lepiej, podsuwam tylko pomysł. Powodzenia.

Dzięki.
Wyłączenie wirtualizacji pomogło (tak na szybko sprawdziłem dla danych testowych).
Jeszcze sprawdzę jak będzie to wpływało na wydajność (wiem, że w jednym ListView mogę mieć max około 5000 wpisów).

Dane trzymam w ObservableCollection, ale użycie reflection i pobieranie danych z property mnie nie urządza.
To ma być eksport zawartości (tego co widać) z ListView, i nie chciałbym aby trafiły tam jakieś nadmiarowe rzeczy.
No i jeszcze kwestia kolejności (w listView mam ustaloną kolejność, natomiast przy property albo bym musiał kombinować, albo bym miał alfabetycznie).

Eksport nie będzie często wykonywany, więc jeżeli wyłączenie wirtualizacji dla ListView będzie jakoś znacząco wpływał na wydajność to zastanowię się, czy w metodzie do eksportu nie sprawdzać typu obiektu. Następnie w zależności od typu, rzutować na ten typ i pobierać potrzebne dane. No, ale tutaj pojawią się kolejne problemy.

Dzisiaj na świeżo zastanawiam się czy nie lepiej byłoby jednak zrobić tak jak ja piszę, do tego, żeby oznaczyć która property i w jakiej kolejności ma być eksportowana możesz wykorzystać Attribute, robisz coś takiego:

public class ExportItem
    {
        [Exportable]
        [ExportIndex(0)]
        public string PropertyA { get; set; }

        [Exportable]
        [ExportIndex(1)]
        public string PropertyB { get; set; }

        public string PropertyC { get; set; }
    }

Oczywiście musisz zaimplementować ExportableAttribute i ExportIndexAttribute, do tych atrybutów możesz się dostać z poziomu refleksji i pobierać w odpowiedniej kolejności tylko te property, które są Exportable, w tej sytuacji PropertyA i PropertyB. Zamiast ObservableCollection<object> w tej sytuacji chyba wykorzystałbym generyka czyli ObservableCollection<TExportableItem> where TExportableItem : class.

ListView dla 5000 bez wirtualizacji może Ci przymulić, co prawda nie stosowałem takich ListView, ale DataGrid z taką ilością danych bez wirtualizacji w WPF jest już naprawdę wolny.

Pozdrawiam.

Dzięki za szczegółową odpowiedź.

Widzę, że jednak muszę do tego tematu podejść na nowo i zabrać się do tego z innej strony.
W ObservableCollection<object> obiektem może być:
-klasa A
-klasa B która dziedziczy po klasie A
żeby było ciekawiej, to w klasach pola są typów prostych (int, string) jak i obiekty innej klasy.
No i jeszcze jest taki myk, że w jednym ListView wyświetlam dane z 2 property a w innym z 4. Nie zawsze pobieram z bazy danych wszystkie dane do uzupełnienia pól klasy.

Twój wpis naprowadził mnie na inny sposób rozwiązania tego problemu.
Niestety nie obejdzie się bez rzutowania na konkretny typ.
Stworzę nowe okno do eksportu, tam sprawdzę jaki typ danych jest w ObservableCollection dla danego ListView. Rzutuję na ten typ (czyli zrobię coś czego chciałem uniknąć), pobiorę nazwy property i dam użytkownikowi do wyboru w formie checkboxów co chcą pobrać (kumaci ludzie, wiec sobie poradzą).

W WinForms nie było by takich problemów :/

To nie jest kwestia tego czy WPF czy WinForms, każdy ma swoje problemy. Ja osobiście po roku pisania w WPF stwierdzam, że jest lepszy, przede wszystkim pozwala mi całkowicie odseparować widok od modelu, MVVM jest naprawdę genialny w swojej istocie. To z czym się ścieramy to zapamiętane podejście z WinForms gdzie wszystko wrzucaliśmy do jednego kotła to jest do code-behind. Co do Twojego problemu to nadal uważam, że możesz to zrobić moją metodą, klasa A no problem, klasa B, która dziedziczy po klasie A, też no problem, ważne, żeby property override lub przesłonięte (new) miały ustawiony attribute w klasie B, te z klasy A zostaną odziedziczone, w trzecim przypadku czyli klasa A zawiera klasę C pod propertą też nie powinno być problemu, możesz oznaczyć klasę C atrybutem jako Exportable i na tej podstawie w refleksji schodzić poziom niżej i przetwarzać tą klasę jeżeli na nią trafisz w propercie. Co zaś do rzutowania na konkretny typ to naprawdę pomyśl nad generykami, pokazując w widoku konkretny viewmodel znasz już typ danych, który się tam znajduje, co więc za problem zrobić jakiś generyczny viewmodel z TExportableItem i w nim zawrzeć już sobie metodę Export(), która poleci po reflection, potem każdy kolejny viewmodel dziedziczy z konkretnym typem i przy okazji dostaje możliwość exportu samego siebie, metodę Export zrób sobie jako virtual gdyby zaszła sytuacja, że czasem musisz coś wyeksportować niestandardowo, albo np. zabronić exportu itd. Możesz też pokombinować tak, że zrobisz sobie abstract metodę do pobierania listy propert do eksportu (z kolejnością), wtedy nie musisz się bawić w reflection, w docelowym viewmodel zaimplementujesz sobie to tak, że pobierzesz listę propert, np. metoda IList<string> BeginExport(), w bazowym viewmodel sobie ją wywołasz, weźmiesz sobie swój TExportableItem jako dynamic i np. dynamicznie dla każdej property zwróconej przez BeginExport() wykonasz sobie eksport, to też jest jakieś wyjście, chociaż stosowania dynamic-ów wiele osób Ci nie zaleci. Nie znam specyfiki, więc tylko podrzucam jakieś pomysły, sam najlepiej będziesz wiedział co pasuje do Twojego projektu, powodzenia.

Trochę napisałem treści, mam nadzieję, że jest czytelne i zrozumiałe, jak nie to daj znać ;) Za błędy jeżeli są z góry przepraszam.

Obczaj sobie FastMember z nuget-a, może Ci się przyda.

Przykład:

ClassA classA = new ClassA();
var wrapper = ObjectAccessor.Create(classA);
var a = wrapper["PropertyA"];
var b = wrapper["PropertyB"];

To tak odnośnie ostatniego zdania gdzie pisałem o pobraniu listy propert w BeginExport() w docelowym viewmodel, a następnie ich wykorzystania w Export() w bazowym viewmodel.
Z dynamic-ami się trochę zapędziłem, to co napisałem wymagałoby użycia ExpandoObject, nie pomyślałem niestety w momencie pisania.

I kolejny raz dzięki.
FastMember chyba rozwiąże moje bolączki.

Co do WPF to też mi lepiej pasuje, ale w tym konkretnym problemie użyłbym listview.items[i].Subitems[j] i miałbym już temat dawno załatwiony.

Wieczorkiem siądę nad kodem zobaczę co z tego wyjdzie.

Już rozwiązałem problem.
Nie jest co prawda doskonały, ale jak dla mnie wystarczający

public static bool Export(ListView lv)
        {
            if (lv == null)
            {
                return false;
            }

            SaveFileDialog saveFileDialog = new SaveFileDialog();
            saveFileDialog.Filter = "csv| *.csv";
            if (saveFileDialog.ShowDialog() == true)
            {
                try
                {
                    GridViewRowPresenter gvrp = lv.GetVisualDescendants<GridViewRowPresenter>().FirstOrDefault();

                    StringBuilder sb = new StringBuilder();
                    int columncount = ((GridView)lv.View).Columns.Count;
                    foreach (GridViewColumn h in ((GridView)lv.View).Columns)
                    {
                        sb.Append("\"" + h.Header.ToString() + "\";");
                    }
                    sb.AppendLine();
                    for (int i = 0; i < lv.Items.Count; i++)
                    {
                        var obElement = lv.Items[i];
                        foreach(TextBlock tb in gvrp.GetVisualDescendants<TextBlock>())
                        {
                            var objSource = BindingOperations.GetBinding(tb, TextBlock.TextProperty);

                            string path = BindingOperations.GetBinding(tb, TextBlock.TextProperty).Path.Path;
                            Binding binding = BindingOperations.GetBinding(tb, TextBlock.TextProperty);
                            
                            var propertyInfo = obElement.GetType().GetProperty(path);
                            string value = string.Empty;
                            if (propertyInfo == null)
                            {
                                try
                                {
                                    ObjectAccessor wrapper = ObjectAccessor.Create(obElement);
                                    var b = wrapper[path.Substring(0,path.IndexOf('.'))];
                                    value = b.GetType().GetProperty(path.Substring(path.IndexOf('.') + 1)).GetValue(b, null).ToString();

                                }catch(Exception)
                                {
                                    return false;
                                }
                            }else
                            {
                                value = obElement.GetType().GetProperty(path).GetValue(obElement, null).ToString();
                            }

                            sb.Append(value + ";");
                        }
                        sb.AppendLine();
                    }
                    File.WriteAllText(saveFileDialog.FileName, sb.ToString());

                    return true;
                }
                catch (Exception)
                {
                    return false;
                }
            }
            return false;
        }

Rozwiązanie nie jest doskonałe przez to:

ObjectAccessor wrapper = ObjectAccessor.Create(obElement);
var b = wrapper[path.Substring(0,path.IndexOf('.'))];
value = b.GetType().GetProperty(path.Substring(path.IndexOf('.') + 1)).GetValue(b, null).ToString();

Ale już tak się zniechęciłem do tego kawałka, że nie kombinowałem nad lepszym rozwiązaniem. Nie mam w żadnym listView elementów które by były tak głęboko, żeby to wywalało.
Temat do zamknięcia, no chyba, że komuś chce się to skończyć.

No właśnie miałeś użyć ObjectAccessor, ale na ViewModel, którym masz listę elementów do bindowania, a nie na ListView.
Właśnie to jest główne założenie w WPF, że całkowicie oddzielamy widok od modelu.

Czyli pod przyciskiem eksportuj robisz Command, który jest w ViewModel i przypinasz do Command metodę, która eksportuje elementy z Items, które masz w ViewModel i bindujesz do ListView. Nigdy nie działamy na widoku. Działanie bezpośrednio na widoku prowadzi do takich właśnie dziwolągów w kodzie, nie wspomnę już, że kod jest nietestowalny.

Pozdrawiam.