microgeek.eu

Potyczki z TreeView

Ostatnio gwałtownie tworzyłem nowe oprogramowanie, gdzie
komponent TTreeView był bardzo istotnym elementem tego programu.
Reminiscencje z terenu walki z relaksacyjną muzą w tlehttps://www.youtube.com/watch?v=QCPbMnwGhbU

Lazarus - zintegrowane środowisko programistyczne (IDE) oparte na kompilatorze Free Pascal. Jest to wzorowane na Delphi wizualne środowisko programistyczne oraz biblioteka Lazarus Component Library (LCL), która jest odpowiednikiem VCL. Program napisany w środowisku Lazarus można bez żadnych zmian skompilować dla dowolnego obsługiwanego procesora, systemu operacyjnego i interfejsu okienek. Lazarus (w większości przypadków) jest zgodny z Delphi. Jest brakującą częścią układanki, która pozwala na rozwijanie programów, podobnie jak w Delphi, na wszystkich platformach obsługiwanych przez FPC. W odróżnieniu od Javy, która stara się, aby raz napisana aplikacja działała wszędzie (write once run anywhere), Lazarus i Free Pascal starają się, aby raz napisana aplikacja kompilowała się wszędzie (write once compile anywhere). Ponieważ dostępny jest dokładnie taki sam kompilator, w większości przypadków nie trzeba wprowadzać żadnych zmian, aby otrzymać taki sam produkt dla różnych platform.
Lazarus zawiera wiele komponentów przydatnych do szybkiego tworzenia aplikacji. Jednym z takich komponentów jest TTreeView → komponent do „obróbki na ekranie” wszelkich zagadnień o strukturze drzewiastej. Sam komponent wygląda jak okienko do przeglądania tekstów.

Budowanie drzewa

Typowym problemem w posługiwaniu się komponentem TreeView jest zasilenie go w dane. Poniższy przykład pokazuje sposób zainicjowania „płaskiej” (jednowarstwowej) struktury danych. W programie, jest utworzona operacja związana z utworzeniem formy programu, w której jest wypełniona wstępnie jakaś struktura drzewa.
W powyższym programie, instrukcja TreeView.Items.Clear; ma za zadanie uwalić dotychczasową istniejącą strukturę (w tym programie to wywołanie nic nie wnosi, gdyż na dzień dobry struktura nie zawiera żadnych danych, jednak w znakomitej większości przypadków istnieje potrzeba „uwalenia” dotychczasowej struktury danych). Kolejne wywołanie RootNode:=TreeView.Items.AddFirst(nil, '<root>'); powoduje utworzenie pierwszego elementu będącego „korzeniem” struktury drzewiastej. Funkcja ta zwraca wskaźnik do utworzonego elementu. W każdym kolejnym wywołaniu TreeView.Items.AddChild(RootNode,'Element 1'); dodawane jest „dziecko” do utworzonego „rodzica” (identyfikowanego zachowanym wskaźnikiem RootNode). Powyższy program daje następujący efekt:jak się kliknie na „+”, to się rozwinie struktura.Efekt rozwiniętej struktury daje się uzyskać programowo na „dzień dobry”. W tym celu należy powyższy ciąg instrukcji uzupełnić instrukcją RootNode.Expanded:=True ;, co oznacza, że wszystkie elementy „dzieci” przynależne do określonego poziomu drzewa będą na dzień dobry rozwinięte.
Kod istotnego fragmentu programu wygląda następująco:Często zachodzi potrzeba utworzenia wstępnej struktury drzewiastej jako bardziej złożonej. Rozpatrzmy taki przykład:Uruchomienie powyższego programu daje następujący efekt na ekranie:Rozwijając wszystkie powyższe elementy powstaje:Łatwo skojarzyć powyższą wyświetloną strukturę z zapisem instrukcji w procedurze inicjującej. Tworzenie struktur drzewiastych może być różnie zagłębione. Kolejny przykład inicjacji:Powyższy program w wyniku uruchomienia daje następujące wyniki:Rozwijając kliknięciem myszki określony element powstaje w kolejnych fazach:Jak widać, zasilanie odpowiednimi danymi struktury TTreeView nie jest sprawą skomplikowaną, jak już się wie jak to zrobić. Do tej pory nie miałem takiej potrzeby, więc nie wgryzałem się w problematykę, jednak ostatnio gwałtownie zaistniała taka potrzeba, więc musiałem pokonać mnóstwo problemów, by uzyskać oczekiwany efekt. Zajęło mi to mnóstwo czasu, więc gdyby jakaś dusza potrzebowała, to może już skorzystać... z przetartych ścieżek.

Potyczki z TreeView
przykład budowania drzewa z „wyższej półki”

z nostalgiczną muzą w tlehttps://www.youtube.com/watch?v=kJ_BJHwkqeI

Dobrym przykładem ilustrującym problematykę zasilania struktury drzewiastej danymi jest próba wyświetlenia struktury kartotek wraz z plikami w nich zawartymi. Załóżmy, że istnieje potrzeba wyświetlenia struktury kartotek wraz z plikami w określonej lokalizacji (to jest po wskazaniu ścieżki dostępu do interesującego miejsca). Z założenia, program ma pokazać zawartość wskazanej kartoteki nie dalej niż jeden poziom w głąb.
Forma programu pokazana jest na ilustracji:Zawiera ona pole do wprowadzenia wskazania na kartotekę, która ma zostać pokazana w okienku TreeView, przycisk do zlecenia wykonania operacji oraz samo okienko TreeView.
Sam program jest następujący:Po wpisaniu w polu edycyjnym wskazania na położenie wyświetlanej kartoteki należy kliknąć na przycisk „Wykonaj”. Spowoduje to wywołanie obsługi kliknięcia przycisku, która w pierwszej kolejności „wczyta z dysku” strukturę wskazanej kartoteki, jako wywołanie funkcji:
TopEntry:=GetFileListe(RootNameEdit.Text,'*.*');
Zawarta jest ona w oddzielnym module (wprost wyjętym w pewnego wiedźmińskiego oprogramowania) i zostanie pokazana w dalszej części. Zadaniem tej funkcji jest „wygarnięcie” z dysku listy kartotek zawartych we wskazanym miejscu. W dalszej kolejności wygarnięte są pliki z każdej napotkanej kartoteki. Efektem działania funkcji jest lista (zwracana jako wskaźnik będący wynikiem funkcji). Lista zbudowana jest z dwóch typów elementów:

• listy nazw kartotek (typ DirFileElementPtr),
• listy nazw plików dowiązanych do danej kartoteki (typ AnyFileElementPtr).

Definicje typów są następujące:orazListy te są powiązane następująco:Jeżeli zwrócony wskaźnik jest różny od nil, to zawiera strukturę pokazaną na powyższej ilustracji. Dane zawarte w tej liście służą do zainicjowania struktury TreeView (pokazania informacji w okienku).
W pierwszej kolejności utworzony jest węzeł root w wyniku wywołania:
RootNode := TreeView . Items . AddFirst ( nil , RootNameEdit . Text ) ;
Dalej są założone dwie pętle: jedna po liście elementów określających nazwy kartotek i druga po liście nazw plików zawartych w danej kartotece. Każde utworzenie węzła:
ElementNode := TreeView . Items . AddChild ( RootNode , TmpEntry ^ . FileName ) ;
dotyczące nazwy kartoteki podaje wskazanie „ojca” jako zmienną RootNode, czyli będą dołączane bezpośrednio do węzła root. Wynik działania funkcji zostaje zawarty w zmiennej ElementNode. Jest to element wskazujący na „ojca” dla elementów dodawanych na następnym poziomie zagłębienia.
Pliki z kolei, są dołączane w wyniku wywołania funkcji:
TreeView . Items . AddChild ( ElementNode , FileEntry ^ . FileName ) ;
gdzie tym razem jako wskazanie na „ojca” występuje zmienna ElementNode. I tak aż do końca listy: jednej jak i drugiej. Po załadowaniu danych do struktur TreeView, wczytana wcześniej lista wskaźnikowa jest zwalniana (w wyniku wywołania DisposeDirListe ( TopEntry ) ;).
Po uruchomieniu programu należy wpisać w odpowiednim polu: e:\microgeek\opublikowane (bo dokładnie tak jest na moim dysku) i walnąć „Wykonaj”.Daje to następujący wynik:i zgadza się to z tym, co pokazuje windozowy eksplorator.Z widoku TreeView wynika, że niektóre elementy nie zawierają elementów „w głąb”, choć w rzeczywistości żadna z kartotek nie jest pusta. Ma to swoje sensowne wyjaśnienie: program nie pokazuje struktury kartotek głębiej niż jeden poziom w głąb. Przykładowo w przypadku kartoteki „Diy-03-fgen” rzeczywista prawda jest następująca:nie ma tu plików (tylko kolejna struktura kartotek) → program z założenia pokazuje tylko jeden poziom zagłębienia.
Rozwinięcie innego elementu pokazuje:co jest zgodne z tym, co zeznaje oprogramowanie windozy:Obiecany wcześniej kawałek oprogramowania prezentuje się następująco:Nie ma tam żadnych nadzwyczajnych rozwiązań, ot zwykła rzemieślnicza robota, którą należy wykonać, bo inaczej nic z tego nie będzie.
Dla tropicieli rozwiązań:

Rekurencyjne podejście do
ładowania danych do TreeView.

z relaksacyjną muzą w tlehttps://www.youtube.com/watch?v=j4_NHGbYtJA

Algorytm wygarniania listy plików zawartych na dysku zaprezentowany w poprzedniej części można zaliczyć do grupy o rozwiązaniu iteracyjnym. Nie jest to szczytowo genialne rozwiązanie, ale spełnia swoją rolę. Specyfika rozwiązywanego zagadnienia jest taka, że zaproponowane doskonale spełnia swoje zadanie. Jednak jak się coś „przymusza” do zachowań, które nie są naturalne w danym rozwiązaniu, to jak się okazuje materia stawia opór. Po prostu wszystko jest dostosowane do swojej roli, którą realizuje, w której doskonale się odnajduje. Przymuszenie algorytmu z poprzedniej części do wygarnięcia całego drzewa z dowolnie długimi gałęziami będzie skomplikowane i nie należy nic robić na siłę.
Jednak czasami zachodzi potrzeba na więcej i w tym miejscu „z nieba spadło” nieoczekiwane rozwiązanie. Nie że bym tego potrzebował, ale skoro już spadło, to można się nad tym rozwiązaniem pochylić. Skoro się tak zdarzyło, to zapewne tak miało być. Niżej zaprezentowany algorytm wygarnia całą strukturę kartotek z dysku do widoku w TreeView i jest rozwiązaniem rekurencyjnym. Wiadomo, pewne rozwiązania są bardziej optymalne w wariancie iteracyjnym (ot choćby pierwszy z brzegu przykład: wyzerowanie tablicy → wszyscy robią to iteracyjnie, co nie znaczy, że nie da się tego zrobić rekurencyjnie), inne w rekurencyjnym. Cała sztuka polega na właściwej ocenie sytuacji i wybrania odpowiedniego rozwiązania.
Zanim zaprezentuję przykład do rekurencyjnego wygarniania zawartości dysku, chcę podziękować obu inspiratorkom. Chylę czoła przed Nataszą, która podesłała mi swój wariant i Wiktorią, która we właściwy dla siebie sposób zainspirowała do działań, które jakoś tak się potoczyły, że powstały „Rozważania na drzewami”.
Pozwoliłem sobie na pewne modyfikacje plików źródłowych, które dostałem od Nataszy. Nie znaczy, że zawierały jakiekolwiek wady, ot po prostu zaadaptowałem to co przychodzi do potrzeb własnego mikrokosmosu.
W Lazarus utworzony jest program, którego forma wygląda następująco:Zawiera ona pole do wprowadzenia położenia korzenia drzewa, maski wyświetlanych plików oraz przycisku do odpalenia rakiety.
Sam program wygląda następująco:Idea rozwiązań rekurencyjnych koncepcyjnie jest bardzo prosta, czasem gorzej jest z realizacją, ale to oddzielny problem. W obsłudze kliknięcia przycisku znajduje się (oprócz uwalenia całego dotychczasowego śmietnika zawartego w strukturach TreeView) utworzenie pierwszego węzła (tego bez rodzica). Zmienna RootNode identyfikuje to miejsce. W dalszej kolejności następuje „zaludnianie” drzewa. Do wywołania rekurencyjnej procedury wniesione zostaje: łańcuch znaków wskazujący na kartotekę, która ma zostać wygarnięta, maska dla plików oraz wskazanie na węzeł, do którego wszystko należy podłączyć (wewnątrz już wywołanej procedury).
Ze „środka” procedury PopulateTree wygląda to następująco:należy „zrobić dir'a” miejsca na dysku określonego przez LocalRootPath i wygarnąć z tego miejsca kartoteki i wszystkie pliki pasujące do maski (LocalFileMask) oraz każdą dołączaną pozycję podczepić pod ojca identyfikowanego przez LocalTreeNode. Przy pierwszym wywołaniu parametry mogą następujące:
LocalRoothPath = 'e:\microgeek'
LocalFileMask = '*.*'
LocalTreeNode → wskazanie na „sztucznie utworzony” węzeł w obsłudze przycisku.
Kawałek softu:przegląda kartotekę wskazaną w wywołaniu (FindFirst(localRootPath+'\*',faAnyFile or faDirectory,FileInfo)) w poszukiwaniu innych kartotek (zawartych lokalnie). W algorytmie olewane są śmieci w postaci „.” i „..”. Jeżeli aktualna pozycja jest kartoteką (pozycje określające pliki są chwilowo olewane), to tworzony jest nowy węzeł:który jest lokalnie zachowany w zmiennej Node. Dalej następuje rekurencyjne wywołanie, które należy zinterpretować jako: dodaj wszystkie dzieci do powstałego ojca, jakkolwiek głęboko by to sięgało.Tu warto zauważyć, że do kolejnego rekurencyjnego wywołania jako wskazanie na kartotekę wniesione są nowe dane powstałe z połączenia tekstu identyfikującego bieżącą kartotekę i nazwy kolejnej kartoteki prowadzącej w głąb drzewa.
Jeżeli program zakończył przeglądanie bieżącej kartoteki w poszukiwaniu elementów „kartotekowych”, przechodzi do drugiej fazy: ponownego przejrzenia bieżącej kartoteki w poszukiwaniu innych „członków rodziny”. Odnalezione klasyczne pliki są „dziećmi”, które należy połączyć z „ojcem” wniesionym z zewnątrz wywołania, z tym, że w tym miejscu do głosu dochodzi maska nazw plików (w fazie poszukiwania kartotek ekwiwalent maski jest '*').Tu znalezione „potomstwo” jest dołączane bezpośrednio do „ojca”.
Generalnie algorytmy rekurencyjne są proste w swej koncepcji działania, trochę gorzej jest z zakumaniem ich działania, to już nie zawsze jest takie proste. Jak się już wie (przynajmniej troszkę, nie koniecznie wszystko, to wszystko zaczyna wyglądać inaczej). Występuje tu pewna bariera pojęciowa, którą należy pokonać. Wiem, bo sam przez to przeszedłem. Strukturami drzewiastymi zajmuję się od tak dawna, że można powiedzieć, że od zawsze. Może kiedyś najdzie mnie wena pisarska i napiszę coś ciekawego o zwykłych drzewach i b-drzewach (to jest dopiero ciekawy wynalazek).
Teraz wracając do programu... przy okazji „łażenia” po różnych zakamarkach na dysku postanowiłem zliczyć kartoteki i zwykłe pliki. Po przejściu całości wynik jest wyświetlany na dole okienka.
Po uruchomieniu programu tradycyjnie podaję „forumową” kartotekę do „molestowania”.Wynik tak troszkę mnie przeraził: tysiąc kartotek i ponad dwadzieścia pięć tysięcy plików. O dzizes... nie spodziewałem się.
Rozklikana struktura bieżącego tematu wygląda następująco:Wprowadziłem maskę, by program wyświetlił tylko pliki zdjęć fotograficznych. Tym razem jest tego znacząco mniej (znaczy liczna kartotek nie uległa zmianie, jest tylko mniej samych plików).Rozwinięcie pozycji „e:\microgeek\opublikowane” z tematem „kryształowe dziecko”:Chwila nostalgii, pamiętam dziewczę, które niezwykle mocno pasjonuje się elektroniką, pozostało kilka fotek. Jak odjeżdżała, to zapowiedziała, że chce jeszcze mnie odwiedzić. Zobaczymy... wszystko zależy od niej.
Temat metalowych obudówek, setki zdjęć.
Dla tropicieli:

No proszę, jak to się ciekawie temat rozwinął. Ładowanie struktury systemu plików do TreeView, czy rekurencyjnie czy jakkolwiek inaczej zmusza kontrolkę ekranową do masy obliczeń na wewnętrzny użytek, dorysowanie kreseczek pomiędzy elementami, ikon (jeżeli są z nimi skojarzone), przy większych ilościach elementów - wykonywane są przeliczenia na suwakach kontrolki (scrollbars).
Aby to wszystko wyłączyć i pozwolić się kontrolce najeść danymi jakby po cichu, bez odświeżania ekranu - wprowadzono dwie komplementarne metody Begin/EndUpdate. Proponuję w metodzie RunButtonClick() na początku samym dostawić TreeView.BeginUpdate; na koniec metody TreeView.EndUpdate; Efekt jest wyraźnie zauważalny przy dużych porcjach danych, sztuczka działa w Lazarus i w Delphi. Polecam, sama korzystam.

Kolejne funkcje TTreeView

Po ostatnich eksperymentach okazuje się, że rzeczywiście zastosowanie odpowiednich zaklęć daje wymierne efekty. Jak zażądać przetworzenia całej struktury dysku, to soft pierwszy raz się sporo natrudził (czas trwania wyraża się w minutach, tak, że nawet naszła mnie sugestia, czy program nie poszedł gdzieś w maliny, jednak konieczne jest wykazanie się jakąś dozą cierpliwości → wyjdzie). Lampka od dysku się wręcz na stałe włączyła i ani myśli zgasnąć. Jak puścić akcję po raz drugi, to czas już spada do kilkunastu sekund. Ot, dobry algorytm cache do potęga.
Tak na fali drzewiastych ciekawostek, to w komponencie TTreeNode jest fajna funkcja: GetPath, która zwraca w postaci string'u listę ojców zaczynając od korzenia a kończąc na jakimś wybranym elemencie (dziecku): coś takiego jak lista rodzinnych pokoleń. Przykład użycia występuje w obsłudze przycisku „Ścieżka”. Jak wcześniej zostanie kliknięta jakaś pozycja (zostanie zaznaczona), to GetPath wyświetla wynik w linii statusowej na dole okienka. Tu przy okazji pokazane jest jak określić jaki element jest zaznaczony. W TTreeView jest funkcja, która zwraca liczbę zaznaczonych elementów. Jeżeli wartość jest różna od zera, to oznacza, że jest zaznaczony minimum jeden element. Ogólnie TTreeView może pracować w trybie MultiSelect (aczkolwiek w tym konkretnym przypadku tak nie jest). Ze względu na MultiSelect zaznaczone elementy są umieszczone w tablicy Selections, gdyż może być ich wiele. Jest ona indeksowana od zera. Jeżeli jest zaznaczony jeden element, to znajduje się pod indeksem 0. Reasumując: TreeView . Selections [ 0 ] . GetTextPath to podanie własnej nazwy wybranego elementu wraz z listą „ojców”. Ponieważ pozycje w drzewie odzwierciedlają realną strukturę plików na dysku, to wynik funkcji odpowiada prawdziwej nazwie dyskowej wskazanej pozycji. Można tą wiedzę jakoś wykorzystać, przykładowo spróbować przejrzeć traktując to jako plik tekstowy (no nie zawsze jest to prawdziwe i czasami można obejrzeć binarne wnętrzności). Można ewentualnie plik usunąć z dysku.
Więc zmodyfikowany program wygląda następująco:Program (przy okazji...) po każdym dołączeniu do węzła całej struktury (czyli po wywołaniu rekurencyjnym oraz po pierwszym wywołaniu z obsługi przycisku) dodałem żądanie rozwinięcia danej gałęzi (Node . Expanded := True ;):
Program odpalony ze wskazaniem na roota dysku daje (po pewnym czasie) następujący wynik. co za śmietnik, ponad 100 tysięcy plików. Tak przewinąłem kawałek i widzę jakieś pliki, których nie kojarzę (no można się zgubić we własnym matriksie).Klik na przycisk „Ścieżka” i już wiadomo, to pliki od instalki programu QUARTUS ściągniętego ze strony ATERA, wersja 7.2 (przedpotopowa), przewijam, jest tego całe mnóstwo. Po jaką chusteczkę mi to? Uwalić.Przewijam dalej, jakieś pliki od C (nie moje), klik i … wiadomo, zainstalowany SDCC (tylko to już któraś kopia na tym samym dysku).
Tak zainspirowany działaniami porządkowymi, posprzątałem własne środowisko, wygarnąłem niepotrzebne śmieci. To nie jest jeszcze koniec porządków, trzeba się będzie nad tym pochylić, ale zrobiłem milowy krok, odchudziłem dysk o kilkadziesiąt tysięcy plików.Normalnie aż lżej się oddycha...

Dla tropicieli: