🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: alt.pl.comp.lang.csharp
Article #10050

Re: Zachowanie stanu w TreeView

#10050
From: NoCode
Date: Sat, 19 Nov 2005 10:45
56 lines
4243 bytes
Użytkownik "Tomasz Muszyński"  napisał w wiadomości
>
> "Realnego doświadczenia"? :) Poprostu jestem programistą od ok. 13 lat...
> Jak już napisał Hilarion, podałem działające rozwiązanie i dosyć wydajne 
> (HashTable poprostu jest wydajne). Kodu za Ciebie nie napiszę. Albo jesteś lub 
> chcesz być programistą, albo układasz cudze klocuszki.

Piszac "realne doswiadczenie" mialem na mysli "realne doswiadczenie w zadanym tu 
problemie" - jasniej -> poszukiwalem kogos kto w swojej aplikacji zachowuje stan 
kontrolki TreeView i potrafi wydajnie go odtwarzac.
I to jest to, o co mi chodzi przez caly czas. Twoje unoszenie sie i poniekad 
obrazanie mojej osoby jest zupelnie nie potrzebne. Odpowiedz na pytanie : "Czy 
rozwiazywalem zadany tu problem, w ktorejs ze swoich ukonczonych aplikacji", 
"Czy zbadalem wydajnosc swojego rozwiazania w pracy z kilku tysiacami wezlow, 
czy udalo mi sie zbadac najlepsza droge ?". Bo z twoich odpowiedzi nie bardzo to 
wyplywa. Ja widze (subiektywnie) twoja podpowiedz jako:
- oznaczenie kazdego wezla
- zapisanie (tu w hashtablu)
- odtworzenie (tu z hashtabla)
no i swietnie. Ale znajdz mi kogos kto tak nie uwaza. Nikt sie z tym nie spiera 
(tak samo jak nikt nie spiera sie z tym, ze jest dzien a po nim jest noc - to 
logiczne), ale niestety nie zbliza mnie to do rozwiazania. Czy chcialbym, zebys 
napisal mi kod ? A dalem ci to do zrozumienia ? Gdzie ?

Probowalem zrozumiec jak do wydajnosci ma sie generowanie kluczy do kazdego z 
kilku tysiecy wezlow, jaki to ma sens ?. Przeciez zakladajac, ze takie 
rozwiazanie daje 100% dokladnosc przy rozpoznawaniu pozniej takich wezlow i tak 
trzeba przeleciec sie po wszystkich wezlach w kontrolce, zeby wykonac ich 
porownywanie... Przy paru tysiacach dociazenie moze byc naprawde ogromne...

Idac dalej - jezeli teraz problem polega na zwyklym rozwinieciu wezlow, ktore 
mialy ten stan przed odrysowaniem to naklad na : generowanie kluczy przy kazdym 
tworzonym wezle oraz tak czy siak przewaleniu sie przez cale drzewo celem 
porownywania jest dla mnie poprostu niewspolmierny. I to probowalem zrozumiec w 
twoim pomysle...

Dlaczego upieralem sie przy FullPatch - poniewaz ograniczy maxymalnie obszar 
poszukiwan - jezeli go nie bedzie - drzewko sie nie rozwinie -> i chyba kazdy 
uzytkownik pracujacy na takiej aplikacji jest w stanie zrozumiec, ze jezeli 
jakis wezel skasowal lub przeniosl to "ma prawo" aplikacja go nie odnalezc. -> I 
to jest dla mnie sedno wydajnosci, o ktorego poszukuje.

>
> Poczytaj sobie do poduszki jeszcze raz co napisałem oraz wypowiedź Hilariona a 
> poznasz proste i wydajne rozwiązanie.
>

Naprawde tak uwazasz ? Bez obrazy, ale chyba lekko sie przeceniasz ...

Juz nie kontynuuje tej polemiki, bo niestety zamiast rozwiazania problemu 
dostalem kilka "podskurnych epitetow".

PS. Lepper tez jest politykiem od ponad 10 lat ... (tylko przyjmij to z humorem) 
;-)

Pozdrawiam
Technical Details
Message-ID: <dlmvnh$afq$1@inews.gazeta.pl>
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.gazeta.pl!not-for-mail
References: <dlf3ot$gkm$1@inews.gazeta.pl> <dlf5vq$ahk$1@nemesis.news.tpi.pl> <dlg7sm$mf5$1@inews.gazeta.pl> <dlgcmv$4tr$1@atlantis.news.tpi.pl> <dlgfp1$eqo$1@nemesis.news.tpi.pl> <dlggsr$459$1@inews.gazeta.pl> <dlj5n4$94h$1@atlantis.news.tpi.pl> <dljssh$t6i$1@inews.gazeta.pl> <dlk5l7$3ki$1@nemesis.news.tpi.pl> <dlk867$d99$1@inews.gazeta.pl> <dlke7h$4em$1@news.onet.pl> <dlkg3m$nge$1@inews.gazeta.pl> <dllk9q$ag1$1@atlantis.news.tpi.pl>

Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.gazeta.pl!not-for-mail
From: "NoCode" <nocode@no-email.com>
Newsgroups: alt.pl.comp.lang.csharp
Subject: Re: Zachowanie stanu w TreeView
Date: Sat, 19 Nov 2005 11:45:02 +0100
Organization: "Portal Gazeta.pl -> http://www.gazeta.pl"
Lines: 57
Message-ID: <dlmvnh$afq$1@inews.gazeta.pl>
References: <dlf3ot$gkm$1@inews.gazeta.pl> <dlf5vq$ahk$1@nemesis.news.tpi.pl> <dlg7sm$mf5$1@inews.gazeta.pl> <dlgcmv$4tr$1@atlantis.news.tpi.pl> <dlgfp1$eqo$1@nemesis.news.tpi.pl> <dlggsr$459$1@inews.gazeta.pl> <dlj5n4$94h$1@atlantis.news.tpi.pl> <dljssh$t6i$1@inews.gazeta.pl> <dlk5l7$3ki$1@nemesis.news.tpi.pl> <dlk867$d99$1@inews.gazeta.pl> <dlke7h$4em$1@news.onet.pl> <dlkg3m$nge$1@inews.gazeta.pl> <dllk9q$ag1$1@atlantis.news.tpi.pl>
NNTP-Posting-Host: ajk158.neoplus.adsl.tpnet.pl
Mime-Version: 1.0
X-Trace: inews.gazeta.pl 1132397105 10746 83.25.244.158 (19 Nov 2005 10:45:05 GMT)
X-Complaints-To: usenet@agora.pl
NNTP-Posting-Date: Sat, 19 Nov 2005 10:45:05 +0000 (UTC)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Priority: 3
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-User: sirstacho
X-MSMail-Priority: Normal
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit