(TRegistry) Sinn von CurrentKey

[Caps]

In der Tat, da kann es Anwendungsfälle geben. Ich wunderte mich bloß, weil in der Hilfe nichts darüber stand.

Alles klar
lg Caps

[Schwedenbitter]

Ich muss mich hier mal einklinken und das Thema wieder aufmachen. Denn man gelangt hierhin, wenn man CurrentKey und/oder CurrentPath in der Suche eingibt:

Weiter oben wurde    property CurrentPath: string read FCurrentPath; schon angesprochen. Bei einem von mir verwendeten Code (Siehe das Thema hier) ist CurrentPath aber immer leer. Der Code-Schnipsel dazu sieht wie folgt aus:

Delphi-Quellcode:

Procedure TMainForm.SearchReg;
Var
   SearchStr   : String;

   Procedure EnumAllKeys(hkey: THandle);
   Var
      l         : TStringList;
      n         : Integer;
      S         : String;
   Begin
      With TRegistry.Create Do
      Try
         RootKey:=hkey;
         OpenKeyReadOnly(EmptyStr);
         l:=TStringList.Create;
         Try
            GetKeynames(l);
            CloseKey;
            For n:=0 To Pred(l.Count) Do
            Begin
               S:=l[n];
               If Pos(SearchStr, UpperCase(S)) > 0 Then
                  LBRegistry.Items.Append(CurrentPath + '#'); // Warum ist das leer???
               If OpenKeyReadOnly(S) Then
               Begin
                  EnumAllKeys(CurrentKey);
                  CloseKey;
               End;
            End;
         Finally
            l.Free
         End;
      Finally
         Free;
      End;
   End;

Begin
   SearchStr:=UpperCase(EDSearch.Text);
   LBRegistry.Items.Clear;
   LBRegistry.Items.BeginUpdate;
   Try
//   EnumAllKeys(HKEY_CLASSES_ROOT    );
//   EnumAllKEys(HKEY_CURRENT_USER    );
      EnumAllKEys(HKEY_LOCAL_MACHINE   );
//   EnumAllKEys(HKEY_USERS           );
//   EnumAllKEys(HKEY_PERFORMANCE_DATA);
//   EnumAllKEys(HKEY_CURRENT_CONFIG  );
//   EnumAllKEys(HKEY_DYN_DATA        );
   Finally
      LBRegistry.Items.EndUpdate;
   End;
End;

Was an meiner Code-Variante ist falsch?

[edit]
Es scheint ein Problem mit CurrentPath zu geben. Anders lässt sich nicht erklären, warum z.B. in diesem Code der jeweilige Pfad durchgereicht und in KeyName_ zwischengespeichert wird.
Ich wäre für Erhellung trotzdem dankbar.
[/edit]

Gruß, Alex

[himitsu]

Wieso sollte das ein Fehler sein?

OpenKeyReadOnly(EmptyStr); aka OpenKeyReadOnly(''); , womit der Pfad also wirklixh '' ist.

Und da vorher auch noch CloseKey; aufgerufen wurde, ist das erst Recht '' , denn dieses Property wird beim Schließen leergemacht.

Es wird zwar danach nochmal der Key geöffnet, aber auch gleich wieder geschlossen, so daß es im nächsten Schleifendurchgang auch wieder korrekt '' ist.



PS: OpenKeyReadOnly hat nicht umsonst ein Result.

[Schwedenbitter]

Zitat von himitsu:

Wieso sollte das ein Fehler sein?

Ich habe doch garnicht das Wort "Fehler" benutzt. Ich habe doch bloß um Erhellung gebeten und die Antwort auch gern zur Kenntnis genommen; also das Problem verstanden. Dafür danke.
Ich habe jetzt eine weitere lokale Variable definiert und darin an mehreren Stellen CurrentPath abgefragt - Ergebnis: immer leer. Das wiederum verstehe ich nicht. Denn wenn die Procedure rekursiv aufgerufen und Rootkey:=hkey; gesetzt wurde, wäre nach meinem Verständnis der aktuelle (Unter)Schlüssel geöffnet. In CurrentPath sollte also nach meinem Verständnis was sinnvolles stehen; tut es aber nicht.
Also formuliere ich meine Frage mal um/anders:

Wie komme ich an den aktuelle Pfad?

Wenn ich den gesuchten String gefunden habe, will ich ja die Fundstelle auch ausgeben.

[himitsu]

Da wo der Key offen ist und wo er nicht mit '' geöffnet wurde, da ist in CurrentKey auch das enthalten, was reingegeben wurde. (der relative Pfad zum RootKey)

An der Stelle, wo du CurrentKey auslesen wolltest, da kannst du auch direkt l[n] , bzw. S verwenden, welches dem CurrentKey entspricht, innerhalb des nachfolgenden IFs.

Delphi-Quellcode:

               S:=l[n];
               If OpenKeyReadOnly(S) Then
               Begin
                  If Pos(SearchStr, UpperCase(S)) > 0 Then
                     LBRegistry.Items.Append(CurrentPath + '#'); // Warum ist das leer???
                  EnumAllKeys(CurrentKey);
                  CloseKey;
               End;

Delphi-Quellcode:

               S:=l[n];
               If Pos(SearchStr, UpperCase(S)) > 0 Then
                  LBRegistry.Items.Append(S + '#'); // Warum ist das leer???
               If OpenKeyReadOnly(S) Then
               Begin
                  EnumAllKeys(CurrentKey);
                  CloseKey;
               End;

[Volker Z.]

Hallo,

Zitat:

Denn wenn die Procedure rekursiv aufgerufen und Rootkey:=hkey; gesetzt wurde, wäre nach meinem Verständnis der aktuelle (Unter)Schlüssel geöffnet

Nö. Das Setzen der Eigenschaft RootKey bestimmt nur den Hauptschlüssel unter dem gelesen/geschrieben werden soll, also HKEY_LOCAL_MACHINE, HKEY_USERS, HKEY_CURRENT_USER etc. - mehr nicht. Die gewünschten Unterschlüssel musst Du schon noch mit OpenKey oder OpenKeyReadOnly entsprechend öffnen (vollständige "Pfadangabe"!).

Wenn Du einen Unterschlüssel öffnest, kannst Du bis zum nächsten CloseKey (sinnvoll) auf CurrentPath zugreifen - nach einem CloseKey steht dann aber nix mehr zur Verfügung.

Versuch es doch mal so:

Delphi-Quellcode:

procedure TForm3.Button1Click(Sender: TObject);
var
  SearchString : string;

  procedure EnumAllKeys (const Root : HKEY; const Key : string);
  var
    r : TRegistry;
    l : TStringList;
    i : Integer;
    s : string;
  begin
    r := TRegistry.Create;
    try
      r.RootKey := Root;

      if r.OpenKeyReadOnly (Key) then
        begin
          l := TStringList.Create;

          r.GetKeyNames (l);
          for i := 0 to l.Count - 1 do
            begin
              s := l [i];
              if Pos (SearchString, UpperCase (s)) > 0 then
                ListBox1.Items.Add (r.CurrentPath + '\' + s);

              EnumAllKeys (Root, r.CurrentPath + '\' + s)
            end;

          r.CloseKey
        end;
    finally
      FreeAndNil (r);
      FreeAndNil (l)
    end
  end;

begin
  SearchString := 'PRINT';
  EnumAllKeys (HKEY_CURRENT_CONFIG, '')
end;

Gruß

[himitsu]

Zitat von Volker Z.:

Hallo

Falls jemand den Code verwendet, beachtet er hoffentlich die Compiler-Warnung, welche meint das L nicht initialisiert sei.
Und das Derjenige den Fehler natürlich auch behebt.

[Schwedenbitter]

Der Code ist sehr schön, bestätigt aber meine Annahme:
Der Pfad zum Key wird mitgeschleift. Wozu dann CurrenPath?

Schlimmer noch ist der Umstand, dass ich CurrentPath jetzt testhalber mal unmittelbar vor dem rekursiven Aufruf eingefügt und mir ausgeben lasse. Es ist jetzt nicht mehr leer - immerhin ein Fortschritt. Aber CurrentPath ist identisch mit s bzw. l[n] und wirft damit wieder die Frage auf: Wozu dann CurrenPath?

Unter "path" verstehe ich eben nicht den aktuellen Key, sondern den gesamten Pfad.

Ich überlege auch, ob ich mein Problem nicht dadurch löse, dass ich mit ShellExecute einfach mal ein reg query HKLM /d /k /v /f "10ec7b9.msp" /s > 10ec7b9.msp.txt laufen lasse und dann die Ausgabe auswerte. Oder kennt jemand durch Zufall eine API-Funktion von Windows, mit der man die Registry nach einem Wert durchsuchen (lassen) kann?

[himitsu]

Weil sicht scheinbar aus einen HKEY kein Pfad auslesen lässt?

CurrentKey gibt immer nur "relativen" den Pfad zurück, welchen du namentlich geöffnet hast.
Wenn du mit RootKey immer nur mitten drin einsteigst, dann kann in der ersten Ebene nie etwas drin stehen.

Natürlich könntest du auch nur den Pfad weiterreichen und RootKey auf dem "Root" belassen, dann würde in CurrentKey auch der relative Pfad zum "Root" drinstehen.