wlasny edytor rejestru

stworzylem wlasny edytor rejestru, ktory bazuje na TRegistry oraz na TTreeView, ale okazuje sie nie w pelni funkcjonalny i jak np chce otworzyc klucz HKEY_CLASSES_ROOT to mija kilka(nascie) sekund zanim ujrze zawartosc tego klucza (program bazuje glownie na funkcji GetKeyNames),
wiec czy znacie zbior funkcji WinApi, ktory usprawnilby moj progam, badz inna propozycje zwiekszenia wydajnosci tego narzedzia?

odopwiedz na pytania typu 'po co ci to?' lub 'przeciez jest regedit...':
a jak na przyklad chce wstawic procedure do 'konia trojanskiego', ktorym moglbym przegladac zawartosc rejestru ofiary?
oraz 'sprawdz na forum'
pod haslem 'edytor rejestru' znalazlem 15 stron wynikow, ktore skutecznie odstraszyly mnie od przegladania...
wniosek i intencja:
czy operator moglby wstawic komponent (badz funkcje), ktorym mozna by bylo wyswietlic wszystkie wyniki na jednej stronie, oraz by mozna bylo wyszukiwac wg tytulow?

a jak na przyklad chce wstawic procedure do 'konia trojanskiego', ktorym moglbym przegladac zawartosc rejestru ofiary?

To wtedy zostaniesz zjechany za pisanie trojanów :-P. Najlepiej otwórz win sdk i szukaj hasła 'registry'. Nic więcej ci nie powiem, bo nie mam tu ani sdk, ani nawet delphi.

przecież normalny regedit też sie przywiesza przy otwieraniu HKEY_CLASSES_ROOT bo jest w nim kilka tysięcy kluczów tak jak i CLSID.

przecież normalny regedit też sie przywiesza przy otwieraniu HKEY_CLASSES_ROOT bo jest w nim kilka tysięcy kluczów tak jak i CLSID.

w pozadku u mnie regedit 'przycina' sie na 1-2 sekundy, a moj program na 1-2 minuty!
robie cos takiego:

procedure Tform1.TreeView1Expanding(Sender: TObject; Node: TTreeNode;
var AllowExpansion: Boolean);
....
begin
....
if (Rejestr.HasSubKeys) and (Node.getFirstChild.Text='' ) then
begin
....
for i:=0 to List.Count-1 do
begin
[1] label1.Caption := inttostr(i)+' / '+inttostr(List.Count-1);
[2] label1.Refresh;
[3] Nod := TreeView1.Items.AddChild( Node, List[i]);
[4] RegTest.OpenKey( Klucz+''+List[i], false );
[5] if (RegTest.HasSubKeys) then
[6] TreeView1.Items.AddChild( Nod, '' );
end;
.....
end;
end;

wlasnie w petli jest zawarty clay mechanizm wykrywania i wstawiania kluczy! jednak w 'potyczce' z kluczem HKEY_CLASSES_ROOT przegrywa z kretesem i zmusza urzytkownika do 1-2 minutowego oczekiwania, z tendencja do spadku wydajnsci przeszukiwania (nawet po usunieciu wszystkich linijek z wyjatkiem linijki[3] i po jej zmodyfikowaniu do najprostrzej formy!)

Używacie BeginUpdate i EndUpdate?

// Do postu poniżej: chodzi o to żeby nie przerysowywać komponentu wiele razy, przy każdorazowym dodaniu nowego itema.

Używacie BeginUpdate i EndUpdate?

w moim koncepcie nie ma potrzeby urzywania tych komend (mam na mysli BeginUpdate i EndUbdate komponentu TTreeView), poniewaz galezie sa dodawane podczas rozwijania i jak widzimy procedura sprawdza czy istnieje klucz (chdzi o TTreeNode) pod nazwa (null), ktory jest dodawany w petli (patrz [6]), a usuwany gdy rozwijamy dany wezel [klucz o nazwie (null) nie moze istniec w rejestrze (co pociaga za soba to, iz nie powstanie taki wezel), wiec taki sposob sprawdzenia czy wezel byl rozwijany jest skuteczny i zadowalajacy]

Application.ProcessMessages w petli? ;p

Application.ProcessMessages w petli? ;p

ta funkcja okazala sie wielce pomocna, jednak nadal nie rozwiazuje glownego zagadnienia jakim jest zminimalizowanie czasu odzwierciedlenia Rejestru (kluczy zawierajacych powyzej 1000 podkluczy) w TreeView-ie ...
ponadto zastosowane przeze mnie rozwiazanie charakteryzuje sie tym, iz petla 'zapycha sie' z z kazdym wzrostem indeksu (zmiennej 'i') petli, co powoduje coraz dluzsze wykonywanie pelnego powtorzenia

ja nie wiem, ja robiłem regedita na ListBoxach i było OK a nawet ładniej wyglądało niż standardowy regedit

Application.ProcessMessages() sprawi, że program nie będzie sprawiał wrażenie powieszonego, ale na pewno wydłuży wyszukiwanie (bo do szukania i dodawania dochodzi jeszcze przetworzenie komunikatów). Może uruchomić to raz na np. 100 przebiegów pętli?

if i mod 100 = 0 then
  Application.ProcessMessages;

hmm, no to daj procedure do wątku i zobacz czy nie będzie lepiej...

niestety nowy watek wprowadza praktycznie to samo co Application.ProcessMessages (ktora i tak w swoim dzialaniu nie wywoluje zauwazalnej zmiany szybkosci dzialania procedury odnajdywania i dodawania kluczy), a jeszcze bardziej spowalnia...
moze inne propozycje i pomysly na przyspieszenie dzialania, badz ma inna procedure?

Nie laduj wszystkiego tylko oprogramuj sobie wirtualne "okno", do ktorego bedziesz wczytywal tylko to co aktualnie widzi uzytkownik.