Zugriff auf Classes\CLSID

[venice2]

Ich mache folgendes.

Delphi-Quellcode:

PRegKey.RootKey := HKEY_LOCAL_MACHINE;
FilePath := 'SOFTWARE\Classes\CLSID';
PRegKey.OpenKey(FilePath, False);

if PRegKey.HasSubKeys then
begin
  PRegKey.GetKeyNames(subKeyFilePath);
  PRegKey.CloseKey;
end;

Man geht eigentlich davon aus CLSID jede menge an SubKeys zur verfügung stellt.
Nur warum werden diese nicht mit PRegKey.HasSubKeys erkannt?

Gibt es hier einen Trick den ich anwenden muss um Zugriff zu bekommen?
Eigentlich sollte der gewährt sein beim lesen.

Nebenbei.
Kann man überhaupt eine ActiveX DLL mit FreeLibrary freigeben?
Falls nicht dann kann ich mir das sparen.

[hoika]

Hallo,
das geht doch nur ReadOnly?

[jaenicke]

Ich vermute einmal, dass die Rechte fehlen und OpenKey schlicht false zurück liefert. Den Rückgabewert ignorierst du leider komplett...

Es gibt stattdessen auch OpenKeyReadOnly, für das du weniger Rechte benötigst.

[venice2]

Zitat:

Zitat von jaenicke (Beitrag 1468841)

Ich vermute einmal, dass die Rechte fehlen und OpenKey schlicht false zurück liefert. Den Rückgabewert ignorierst du leider komplett...

Es gibt stattdessen auch OpenKeyReadOnly, für das du weniger Rechte benötigst.

Ich ignoriere gar nichts denn ich habe nur das gepostet was im Context zu meiner Frage stand.
Werde es mal mit OpenKeyReadOnly versuchen.

Dann noch mal nicht geschrieben sondern eingefügt. (copy\paste)

Delphi-Quellcode:

            FilePath := 'SOFTWARE\Classes\CLSID\';
            if PRegKey.OpenKey(FilePath, False) then
            begin
              if PRegKey.HasSubKeys then
              begin
                PRegKey.GetKeyNames(subKeyFilePath);
                PRegKey.CloseKey;
              end;
            end;

funktioniert genau sowenig.
Wie komme ich sonst an die Pfade der DLL's ?

[himitsu]

Nur weil man die Rückgabewerte (teilweise) auswertet, funktioniert der Code nicht plörlich, wenn er auch Ohne bereits Fehler ausgelöst hatte und sich an der eigentlich Funktion garnichts geändert hat.

Wenn man aber die Rückgaben "richtig" auswerten würde, dann wüsste man wenigstens warum es nicht geht.

[venice2]

Zitat:

Zitat von himitsu (Beitrag 1468845)

Nur weil man die Rückgabewerte (teilweise) auswertet, funktioniert der Code nicht plörlich, wenn er auch Ohne bereits Fehler ausgelöst hatte und sich an der eigentlich Funktion garnichts geändert hat.

Wenn man aber die Rückgaben "richtig" auswerten würde, dann wüsste man wenigstens warum es nicht geht.

Richtig.
Nur es hilft mir leider nicht bei meinem Problem wie ich an den Pfad der DLL komme.

[himitsu]

Delphi-Quellcode:

FilePath := 'SOFTWARE\Classes\CLSID\';
if PRegKey.OpenKey(FilePath, False) then
begin

end
else
  RaiseLastOSError;

Und schon gelesen was die Anderen schrieben?

Wer möchte raten, was mit Close nach dem Open passiert, wenn es keine SubKeys gibt?

Zitat:

Delphi-Quellcode:

if PRegKey.OpenKey(FilePath, False) then
begin
  if PRegKey.HasSubKeys then
  begin
    ...
    PRegKey.CloseKey;

[venice2]

Zitat:

Zitat von himitsu (Beitrag 1468848)

und schon gelesen was die anderen schrieben?

Entschuldige.
Schon gelesen?

Zitat:

Ich ignoriere gar nichts denn ich habe nur das gepostet was im Context zu meiner Frage stand.

Es geht nicht darum ob ich einen Key schließe (was ich natürlich tue) sondern darum warum ich keinen Zugriff bekomme.
Ob ich dann RaiseLastOSError; auswerte ist doch eine ganz andere Geschichte.

Alles andere hat schon seine Richtigkeit.
Ich kann den Key nicht öffnen versuche es doch einfach einmal.
Danke!

[Uwe Raabe]

Ich kann - mit einer marginalen Modifizierung deines Codes gemäß der Empfehlung von Sebastian:

Delphi-Quellcode:

      FilePath := 'SOFTWARE\Classes\CLSID\';
      if PRegKey.OpenKeyReadOnly(FilePath) then
      begin
        if PRegKey.HasSubKeys then
        begin
          PRegKey.GetKeyNames(subKeyFilePath);
          PRegKey.CloseKey;
        end;
      end;

[venice2]

Zitat:

Zitat von Uwe Raabe (Beitrag 1468850)

Ich kann - mit einer marginalen Modifizierung deines Codes gemäß der Empfehlung von Sebastian:

Delphi-Quellcode:

      FilePath := 'SOFTWARE\Classes\CLSID\';
      if PRegKey.OpenKeyReadOnly(FilePath) then
      begin
        if PRegKey.HasSubKeys then
        begin
          PRegKey.GetKeyNames(subKeyFilePath);
          PRegKey.CloseKey;
        end;
      end;

Nun dann öffnest du den Key mit Adminrechten denn bei mir geht es nicht.
Gleicher Code. (Ich öffne den Key in einer DLL, vergessen zu sagen)

Auch nicht mit 'SOFTWARE\Classes\Wow6432Node\CLSID';

EDIT.
bzgl. OpenKeyReadOnly und OpenKey

Zitat:

Just use OpenKey instead of OpenKeyReadOnly, this won't reset your Access property.

siehe

Nochmal komplett. Ohne PRegKey.CloseKey; wird aber verwendet

Delphi-Quellcode:

PRegKey := TRegistry.Create(KEY_READ);
PRegKey.RootKey := HKEY_LOCAL_MACHINE;
            
FilePath := 'SOFTWARE\Classes\Wow6432Node\CLSID'; // ob ich direkt auf Wow6432Node gehe oder nicht sollte eigentlich egal sein.
if PRegKey.OpenKey(FilePath, False) then
  begin
    if PRegKey.HasSubKeys then
    begin
      PRegKey.GetKeyNames(subKeyFilePath);
      PRegKey.CloseKey;
    end;
end;

[Uwe Raabe]

Zitat:

Zitat von venice2 (Beitrag 1468852)

Nun dann öffnest du den Key mit Adminrechten denn bei mir geht es nicht.

OpenKeyReadOnly verwendet lediglich KEY_READ als Access-Code, während OpenKey mit KEY_ALL_ACCESS arbeitet (falls nicht absichtlich geändert). Der Hinweis aus dem Link zieht hier ja ganz bewusst nicht, da ich ja gezielt den Access-Code so ändern will, damit ich das lesen kann. Es hat auch nichts mit Adminrechten zu tun, denn bei mir liefert ein OpenKey auch auch kein Ergebnis.

Wenn nicht noch irgendwelche anderen Bedingungen gelten, von denen wir nichts wissen, dann sollte auch der Zugriff aus einer DLL kein Problem darstellen.

[venice2]

Zitat:

Zitat von Uwe Raabe (Beitrag 1468853)

Zitat:

Zitat von venice2 (Beitrag 1468852)

Nun dann öffnest du den Key mit Adminrechten denn bei mir geht es nicht.

OpenKeyReadOnly verwendet lediglich KEY_READ als Access-Code, während OpenKey mit KEY_ALL_ACCESS arbeitet (falls nicht absichtlich geändert). Der Hinweis aus dem Link zieht hier ja ganz bewusst nicht, da ich ja gezielt den Access-Code so ändern will, damit ich das lesen kann. Es hat auch nichts mit Adminrechten zu tun, denn bei mir liefert ein OpenKey auch auch kein Ergebnis.

Wenn nicht noch irgendwelche anderen Bedingungen gelten, von denen wir nichts wissen, dann sollte auch der Zugriff aus einer DLL kein Problem darstellen.

Ok Danke.
Dann weis ich auch nicht mehr weiter. (Windows 10 halt)
Ich bekomme keinen Zugriff und mehr als im gezeigten Code tue ich nicht um den KEY zu lesen.

[Uwe Raabe]

Hast du es mal aus einem simplen Testprogramm heraus versucht?

[venice2]

Zitat:

Zitat von Uwe Raabe (Beitrag 1468855)

Hast du es mal aus einem simplen Testprogramm heraus versucht?

Könnte ich mal machen.

[Uwe Raabe]

Zum Beispiel dies hier:

Delphi-Quellcode:

program Project700;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils,
  System.Classes,
  System.Win.Registry,
  Winapi.Windows;

procedure Main;
var
  FilePath: string;
  PRegKey: TRegistry;
  subKeyFilePath: TStringList;
begin
  subKeyFilePath := TStringList.Create();
  try
    PRegKey := TRegistry.Create;
    try
      PRegKey.RootKey := HKEY_LOCAL_MACHINE;
      FilePath := 'SOFTWARE\Classes\CLSID\';
      if PRegKey.OpenKeyReadOnly(FilePath) then
      begin
        if PRegKey.HasSubKeys then
        begin
          PRegKey.GetKeyNames(subKeyFilePath);
          PRegKey.CloseKey;
        end;
      end;
    finally
      PRegKey.Free;
    end;
    Writeln(subKeyFilePath.Text);
  finally
    subKeyFilePath.Free;
  end;
end;

begin
  try
    Main;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
  Readln;
end.

[venice2]

Einfache EXE funktioniert aus DLL der gleiche Code nicht.
Warum?

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  FilePath: string;
  res: BOOL;
begin
   PRegKey := TRegistry.Create(KEY_READ);
   PRegKey.RootKey := HKEY_LOCAL_MACHINE;
   FilePath := 'SOFTWARE\Classes\Wow6432Node\CLSID';
   res := PRegKey.OpenKey(FilePath, False);
   if res then
   begin
     if PRegKey.HasSubKeys then
     begin
//        PRegKey.GetKeyNames(subKeyFilePath);
        PRegKey.CloseKey;
     end;
   end;
   PRegKey.Free; 
end;

Ich bekomme den Zugriff mit OpenKeyReadOnly oder OpenKey denke der ausschlaggebende punkt hierbei ist wie die Registry erstellt wird.
Bei mir mit KEY_READ
Es geht mit 'SOFTWARE\Classes\Wow6432Node\CLSID'; und ohne Wow6432Node 'SOFTWARE\Classes\CLSID'; daran liegt es nicht.

[Uwe Raabe]

Zitat:

Zitat von venice2 (Beitrag 1468858)

Einfache EXE funktioniert aus DLL der gleiche Code nicht.

Auch nicht mit einer neuen, sonst nackten DLL nicht?

Zitat:

Zitat von venice2 (Beitrag 1468858)

Ich bekomme den Zugriff mit OpenKeyReadOnly oder OpenKey denke der ausschlaggebende punkt hierbei ist wie die Registry erstellt wird.
Bei mir mit KEY_READ

Ja, in dem Fall sollte auch OpenKey funktionieren.

[venice2]

Das ist auch seltsam.
Mal mit der Exe getestet.

Delphi-Quellcode:

     
     if subKeyFilePath.Count > 0 then
       for I := 0 to subKeyFilePath.Count - 1 do
       begin
         if subKeyFilePath[i] = '{43D2E184-46AC-11d4-A8AF-00105AC582C2}' then
         begin
           if PRegKey.OpenKey(FilePath + '\' + subKeyFilePath[i] + '\InprocServer32', False) then
           begin
             Path := PRegKey.ReadString('(Standard)');
             Label1.Caption := Path;
           end;
           break;
         end;
       end;

gebe ich anstelle von '(Standard)' ThreadingModel an dann wird Apartment zurück gegeben.
Bei der default Value immer ein Leerstring und genau hier steht der Pfad zur DLL.

Zitat:

Auch nicht mit einer neuen, sonst nackten DLL nicht?

Hab ich noch nicht getestet.

Das ist ärgerlich.
Ich habe vorher die DLL (ActiveX) mit CoCreateInstance initialisiert.

Nun habe ich gedacht weil diese sich nicht entladen ließ versuche ich die Typelib zur Laufzeit zu laden.
Also mit LoadLibrary in Verbindung mit LoadTypeLib

Um dann über FreeLibrary die DLL zu entladen wenn sie nicht mehr gebraucht wird.
Das funktioniert ebenfalls nicht selbst wenn ich ein gültiges Handle davon habe. :stupid:
Ich kann das im Prozess Explorer verfolgen.

Das ist zum Haare raufen.

Hier dein Beispiel nochmal zurück mit meiner Änderung.

Delphi-Quellcode:

program Project2;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  SysUtils,
  Classes,
  Registry,
  Windows;

procedure Main;
var
  FilePath: string;
  Path: string;
  PRegKey: TRegistry;
  subKeyFilePath: TStringList;
  i: Integer;
begin
  subKeyFilePath := TStringList.Create();
  try
    PRegKey := TRegistry.Create;
    try
      PRegKey.RootKey := HKEY_LOCAL_MACHINE;
      FilePath := 'SOFTWARE\Classes\CLSID\';
      if PRegKey.OpenKeyReadOnly(FilePath) then
      begin
        if PRegKey.HasSubKeys then
        begin
          PRegKey.GetKeyNames(subKeyFilePath);
          PRegKey.CloseKey;
        end;
      end;

    Writeln(subKeyFilePath.Text);

    if subKeyFilePath.Count > 0 then
       for I := 0 to subKeyFilePath.Count - 1 do
       begin
         if subKeyFilePath[i] = '{43D2E184-46AC-11d4-A8AF-00105AC582C2}' then
         begin
           if PRegKey.OpenKey(FilePath + '\' + subKeyFilePath[i] + '\InprocServer32', False) then
           begin
             Path := PRegKey.ReadString('ThreadingModel'); // mit (Standard) ersetzen verursacht Probleme Leerstring wird zurück gegeben.
             Writeln('GetValue := ' + Path);
             break;
           end;
         end;
       end;
    finally
      PRegKey.Free;
    end;
  finally
    subKeyFilePath.Free;
  end;
end;

begin
  try
    Main;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
  Readln;
end.

[himitsu]

Zitat:

Zitat von venice2 (Beitrag 1468849)

Ich ignoriere gar nichts denn ich habe nur das gepostet was im Context zu meiner Frage stand.

... sondern darum warum ich keinen Zugriff bekomme.[/QUOTE]

OK, dann bin ich mal weg.

Entweder du willst wissen warum es nicht geht oder nicht, aber wenn nicht, dann heul nicht rum.

Delphi-Quellcode:

if PRegKey.OpenKey(...

else
  WriteLn(PRegKey.LastErrorMsg); //RaiseLastOSError(PRegKey.LastError);

Ich bekomme da erstmal das Wichtigste bei raus.
* Zugriff verwigert
* Pfad nicht gefunden
* Pfad ungültig
* ...

Bei Ersterem geh ich dann in den Registryeritor und schau mit dir Berechtigungen an
z.B. HKEY_LOCAL_MACHINE\SOFTWARE : Admin=Vollzugriff und Benutzer=NurLesen

Und falls du grade mit etwas anderem als Admin oder Benutzer unterwegs bist, dann können wir das nicht wissen, es sei denn jemand sagt etwas.

Zitat:

Es geht nicht darum ob ich einen Key schließe (was ich natürlich tue)

Nein, du machst es nicht immer.
Nja, es kommt auch drauf an warum man es wann macht.

In deinem Fall wird es dort nur gemacht, damit es beim nächsten OpenKey nicht knallt, was man dann schon besser mal als Kommentar dahinter schreiben sollte, sonst weiß es niemand.
OK, da TRegistry mit relativen Pfaden arbeitet, wäre es vielleicht stattdessen "logischer" mit absuluten Pfadangaben zu arbeiten, wenn man diese übergibt.


Ob EXE oder DLL ist total egal, denn der Prozess, bzw. der Thread hat die Rechte und wo der Code ausgeführt wird interessiert niemanden. (außer vielleicht jemand kommt auf die Idee sowas z.B. in einem Virenscanner einzubauen, aber bis jetzt noch nicht)


Und ja, bei mir wird das Verzeichnis problemlos ausgelesen,
außer dass es anschließend das {43D2E184-46AC-11d4-A8AF-00105AC582C2} hier nicht gibt.

[venice2]

Zitat:

Und ja, bei mir wird das Verzeichnis problemlos ausgelesen

Ja mit meinem Exe Example auch sowie mit dem vom Uwe.

Zitat:

Entweder du willst wissen warum es nicht geht oder nicht, aber wenn nicht, dann heul nicht rum.

Ok du hast ja recht werde PRegKey.LastErrorMsg in meiner DLL mal anhängen.

Das ergebniss.

Delphi-Quellcode:

            PRegKey.RootKey := HKEY_LOCAL_MACHINE;
            FilePath := 'SOFTWARE\Classes\CLSID\';
            if PRegKey.OpenKey(FilePath, False) then
            begin
              if PRegKey.HasSubKeys then
              begin
                PRegKey.GetKeyNames(subKeyFilePath);
                PRegKey.CloseKey;
              end;
            end else
            begin
              FilePath := (PRegKey.LastErrorMsg);
              PRegKey.CloseKey;
            end;

Das System kann die angegebene Datei nicht finden. (wenn aus der DLL aufgerufen)
Seltsam. Was für eine Datei?

[mmw]

Hallo,

vielleicht hilft dies.

PRegKey:=TRegistry.Create(KEY_READ or KEY_WOW64_64KEY);

Gruß

[Uwe Raabe]

Ich glaube zwar nicht, dass es in diesem Fall irgendetwas bewirkt, aber eigentlich solltest du HKEY_CLASSES_ROOT nehmen und den SubKey leer lassen. Das liefert dir die effektive Sicht deiner Applikation auf die COM-Registrierung, inklusive der per-User Registrierungen.

Siehe: HKEY_CLASSES_ROOT Key

Zitat:

Registry functions such as RegOpenKeyEx or RegQueryValueEx allow you to specify the HKEY_CLASSES_ROOT key. When you call these functions from a process running in the interactive user account, the system merges the default settings in HKEY_LOCAL_MACHINE\Software\Classes with the interactive user's settings at HKEY_CURRENT_USER\Software\Classes. For more information on how these settings are merged, see Merged View of HKEY_CLASSES_ROOT.

[venice2]

Zitat:

Zitat von mmw (Beitrag 1468863)

Hallo,

vielleicht hilft dies.

PRegKey:=TRegistry.Create(KEY_READ or KEY_WOW64_64KEY);

Gruß

Danke aber nein.
Dazu hatte ich schon etwas verlinkt.

[venice2]

Zitat:

Zitat von Uwe Raabe (Beitrag 1468865)

Ich glaube zwar nicht, dass es in diesem Fall irgendetwas bewirkt, aber eigentlich solltest du HKEY_CLASSES_ROOT nehmen und den SubKey leer lassen. Das liefert dir die effektive Sicht deiner Applikation auf die COM-Registrierung, inklusive der per-User Registrierungen.

Siehe: HKEY_CLASSES_ROOT Key

Zitat:

Registry functions such as RegOpenKeyEx or RegQueryValueEx allow you to specify the HKEY_CLASSES_ROOT key. When you call these functions from a process running in the interactive user account, the system merges the default settings in HKEY_LOCAL_MACHINE\Software\Classes with the interactive user's settings at HKEY_CURRENT_USER\Software\Classes. For more information on how these settings are merged, see Merged View of HKEY_CLASSES_ROOT.

Leider nein.
Aber HKEY_CURRENT_USER scheint zu funktionieren.
Aber dort befindet sich die ClassID nicht.

[Uwe Raabe]

OK, SubKey ganz leer lassen stimmt nicht so wirklich, aber mit dieser Code-Änderung bekomme ich zumindest ein brauchbares Ergebnis:

Delphi-Quellcode:

      PRegKey.RootKey := HKEY_CLASSES_ROOT;
      FilePath := 'CLSID\';

[venice2]

Zitat:

Zitat von Uwe Raabe (Beitrag 1468870)

OK, SubKey ganz leer lassen stimmt nicht so wirklich, aber mit dieser Code-Änderung bekomme ich zumindest ein brauchbares Ergebnis:

Delphi-Quellcode:

      PRegKey.RootKey := HKEY_CLASSES_ROOT;
      FilePath := 'CLSID\';

Danke aber dort wird die ClassID nicht gefunden.

[Uwe Raabe]

Zitat:

Zitat von venice2 (Beitrag 1468871)

Danke aber dort wird die ClassID nicht gefunden.

Welche? Eine bestimmte? Dann ist die vielleicht unter einem anderen User-Account registriert? In dem Fall wäre sie auch nicht in HKEY_LOCAL_MACHINE zu finden.

[venice2]

Zitat:

Zitat von Uwe Raabe (Beitrag 1468872)

Zitat:

Zitat von venice2 (Beitrag 1468871)

Danke aber dort wird die ClassID nicht gefunden.

Welche? Eine bestimmte? Dann ist die vielleicht unter einem anderen User-Account registriert? In dem Fall wäre sie auch nicht in HKEY_LOCAL_MACHINE zu finden.

Doch ich finde sie.

Aber! Manchmal sitzt das Problem vor dem Monitor.
Man vergleiche.

Delphi-Quellcode:

PRegKey.RootKey := HKEY_LOCAL_MACHINE;
FilePath := 'SOFTWARE\Classes\CLSID\';

Delphi-Quellcode:

if PRegKey.OpenKey(FilePath + '\' + subKeyFilePath[i] + '\InprocServer32', False) then

Vielleicht erkennt ja jemand meinen Fehler ;)

Desto-trotz ist die Abfrage nach dem Pfad = NULL
Keine Ahnung wie ich eine Positive Rückgabe bekomme wenn ich den Default wert eintrage.

Delphi-Quellcode:

Path := PRegKey.ReadString('ThreadingModel'); // mit (Standard) ersetzen

Bekommt man hier grundsätzlich keine Rückgabe?

Danke für eure Hilfe

EDIT:
Grrr.. war die EXE Problem bleibt trotzdem bestehen. Datei wird nicht gefunden. (DLL)
Muss im Moment mal Abstand davon nehmen komme zu keinem Ergebnis.

[jaenicke]

Du hast ja den Process Explorer angesprochen. Hast du auch einmal den Process Monitor verwendet? Dort siehst du ja die einzelnen Registry Zugriffe, ob sie erfolgreich waren, den richtigen Pfad verwenden, usw.

[venice2]

Zitat:

Zitat von jaenicke (Beitrag 1468874)

Du hast ja den Process Explorer angesprochen. Hast du auch einmal den Process Monitor verwendet? Dort siehst du ja die einzelnen Registry Zugriffe, ob sie erfolgreich waren, den richtigen Pfad verwenden, usw.

Ich muss das revidieren. Sorry Uwe hat recht es geht auf diese weise mit der EXE. Key wird gefunden.
Das Problem mit dem Leerstring bleibt jedoch bestehen.

Delphi-Quellcode:

PRegKey.RootKey := HKEY_CLASSES_ROOT;
FilePath := 'CLSID\';

Bin momentan komplett gegen den Wind. :oops:

[Uwe Raabe]

Könnte es an Groß-/Kleinschreibung der Keys liegen? Probeweise mal den Vergleich mit SameText machen.

[venice2]

Zitat:

Zitat von Uwe Raabe (Beitrag 1468876)

Könnte es an Groß-/Kleinschreibung der Keys liegen? Probeweise mal den Vergleich mit SameText machen.

Denke nicht.
Habe die Zeichenfolge exakt aus der Registry kopiert.

Was für ein Ärger
Funktioniert nicht was man aber eigentlich voraussetzt
Path := PRegKey.ReadString('(Standard)');

Funktioniert.
Path := PRegKey.ReadString('');

Was für eine Logik. (Denke hat mit den unterschiedlichen Länder Sprachen zu tun.) English = Default, Deutsch = Standard
Um die Sprachen zu umgehen nimmt man dann hier einfach einen Leerstring. Wie auch immer

So geht es nun.
Danke nochmal an alle.

[jaenicke]

Zitat:

Zitat von venice2 (Beitrag 1468878)

Funktioniert nicht was man aber eigentlich voraussetzt
Path := PRegKey.ReadString('(Standard)');

Funktioniert.
Path := PRegKey.ReadString('');

(Standard) ist nur eine Anzeige im Registryeditor für einen leeren String als Name des Wertes! Eben weil das der nicht weiter benannte Standardwert ist.

[venice2]

Zitat:

Zitat von jaenicke (Beitrag 1468880)

Zitat:

Zitat von venice2 (Beitrag 1468878)

Funktioniert nicht was man aber eigentlich voraussetzt
Path := PRegKey.ReadString('(Standard)');

Funktioniert.
Path := PRegKey.ReadString('');

(Standard) ist nur eine Anzeige im Registryeditor für einen leeren String als Name des Wertes! Eben weil das der nicht weiter benannte Standardwert ist.

OK :)
Dann weis ich nun bescheid warum es nicht funktioniert hat.

[Uwe Raabe]

Das ist mal wieder ein klassisches Beispiel für den Wert reproduzierbaren Test-Codes. Ich bin die ganze Zeit davon ausgegangen, daß der Zugriff auf InprocServer32 kein Ergebnis liefert.

[venice2]

Zitat:

Zitat von Uwe Raabe (Beitrag 1468882)

Das ist mal wieder ein klassisches Beispiel für den Wert reproduzierbaren Test-Codes. Ich bin die ganze Zeit davon ausgegangen, daß der Zugriff auf InprocServer32 kein Ergebnis liefert.

Stimmt schon.
Aber ich schrieb ja

Delphi-Quellcode:

Path := PRegKey.ReadString('ThreadingModel'); // mit (Standard) ersetzen

ThreadingModel. funktioniert und mit (Standard) ersetzen nicht.