TRegistry Unterschied zwischen Delphi 7 und 2009

[Shark99]

Hallo!

ich bin dabei ein Projekt von Delphi 7 auf Delphi 2009 umzuschreiben.

Es crasht und ich merkte es liegt am Zugriff bei TRegistry.

Der Code ist sehr einfach:

Delphi-Quellcode:

FRegistry :=  TRegistry.Create;
FRegistry.RootKey := HKEY_CURRENT_USER;
if FRegistry.OpenKey('\Software\Vendor\Productname', True) then
begin
  // Alles OK, Key war schon da, oder wurde erstellt
  ...
end else
begin
  // Fehler
  ...
end;

Das Klappt unter Delphi 7 wunderbar (Exe funktioniert unter Win 7 x64 und Win 8.1 x64, und zwar auch ohne Admin-Rechte). Der Key ist schon vorhanden und wird geöffnet. Wenn ich jedoch mit Delphi 2009 kompiliere und ausführe wird der Key nicht geöffnet, sondern der Code bei // Fehler ausgeführt.

Wenn ich nun Testweise TRegistry.Create mit TRegistry.Create(KEY_READ) ersetze wird der Key hingegen geöffnet. Das Problem ist aber leider nicht gelöst, weil das FRegistry Objekt diesen Key nicht nur ausliest, sondern beim Programmbeenden auch beschreibt.

Wie sind die TRegistry.Create() Parameter damit ich HKEY_CURRENT_USER sowohl lesen, als auch beschreiben kann?

Ich versuchte es kurz mit KEY_ALL_ACCESS versucht. Key wird damit nichtmal geöffnet (wieso nicht?). Als nächstes KEY_READ or KEY_WRITE, Key wird auch nicht geöffnet.

Neuer versuch: KEY_READ AND KEY_WRITE, Key wird geöffnet, aber der danach versuchte ReadBool() liefert ein falsches Ergebnis (mit nur KEY_READ das Richtige).

Bin leider mit meinem Latein am Ende. :oops:

[Perlsau]

Ist das, was in der Online-Hilfe steht, nicht hilfreich?

Delphi-Quellcode:

constructor Create; overload;
constructor Create(AAccess: LongWord); overload;

Mit Create wird ein TRegistry-Objekt instantiiert. Dabei erhält die Eigenschaft RootKey den Wert HKEY_CURRENT_USER und die Eigenschaft LazyWrite den Wert true. Wenn der Parameter AAccess übergeben wird, wird dessen Wert für die Initialisierung der Eigenschaft Access verwendet. Ansonsten wird Access mit KEY_ALL_ACCESS initialsiert.

Delphi-Quellcode:

{
This example shows how to use the TRegistry class in order to
find, insert and delete Keys and Items into the Windows Registry.
This example uses two buttons: InsertToRegBtn and DeleteFromRegBtn,
on a form, for inserting and deleting the values.
}
procedure TForm3.InsertToRegBtnClick(Sender: TObject);
var
  reg        : TRegistry;
  openResult : Boolean;
  today      : TDateTime;
begin
  reg := TRegistry.Create(KEY_READ);
  reg.RootKey := HKEY_LOCAL_MACHINE;

  if (not reg.KeyExists('Software\\MyCompanyName\\MyApplication\\')) then
    begin
      MessageDlg('Key not found! Created now.',
                            mtInformation, mbOKCancel, 0);
    end;
  reg.Access := KEY_WRITE;
  openResult := reg.OpenKey('Software\\MyCompanyName\\MyApplication\\',True);

  if not openResult = True then
    begin
      MessageDlg('Unable to create key! Exiting.',
                  mtError, mbOKCancel, 0);
      Exit();
    end;

  {checking if the values exist and inserting when neccesary}

  if not reg.KeyExists('Creation\ Date') then
    begin
      today := Now;
        reg.WriteDateTime('Creation\ Date', today);
    end;

  if not reg.KeyExists('Licenced\ To') then
    begin
        reg.WriteString('Licenced\ To', 'MySurname\ MyFirstName');
    end;

  if not reg.KeyExists('App\ Location') then
    begin
        reg.WriteExpandString('App\ Location',
                            '%PROGRAMFILES%\\MyCompanyName\\MyApplication\\');
    end;

  if not reg.KeyExists('Projects\ Location') then
    begin
        reg.WriteExpandString('Projects\ Location',
                            '%USERPROFILE%\\MyApplication\\Projects\\');
    end;

  reg.CloseKey();

end;

procedure TForm3.DeleteFromRegBtnClick(Sender: TObject);
var
  reg : TRegistry;
begin
  reg := TRegistry.Create(KEY_WRITE);
  reg.RootKey := HKEY_LOCAL_MACHINE;

  reg.DeleteKey('Software\\MyCompanyName\\MyApplication');
  reg.DeleteKey('Software\\MyCompanyName');

  reg.CloseKey();
end;

[Shark99]

Perlsau, nein das hilft nicht.

Es geht hier um Code der sich Unter Delphi 7 und Delphi 2009 komplett anders verhält. Die Hilfe sagt kein Wort wieso KEY_READ OR KEY_WRITE bzw KEY_ALL_ACCESS in Verbindung mit HKEY_CURRENT_USER gar nicht funktioniert.

[jaenicke]

Ich würde einmal mit dem Process Monitor schauen was eigentlich passiert im Vergleich. Den Filter solltest du auf "Process Name is <Name deiner Exe>" setzen und zudem "Operation begins with Reg". Dann solltest du recht schnell sehen was passiert.

[Bernhard Geyer]

Nimm mal beim Pfad das führende Backslahs weg. Also Statt '\Software\Vendor\Productname' -> 'Software\Vendor\Productname'

[Popov]

Ich weiß, vielleicht wird das etwas OT, aber ich hab nie verstanden was so toll daran sein soll auf HKEY_CURRENT_USER, bzw. speziell auf "Software" über die TRegistry zuzugreifen, falls man nur 08/15 Daten drauf ablegen will. Nur um eine String abzuspeichern verbiegen sich einige mit dem Rattenschwanz an Zeilen, dabei bietet Delphi einen einfachen Zugriff. Solange es HKEY_CURRENT_USER ist.

[jaenicke]

Wenn du damit auf TRegIniFile hinaus willst:
Das ist nur eine Krücke um eine Migration der alten INIs von Windows 3.x auf Windows 9x und höher einfacher zu machen. Für neue Implementierungen macht es normalerweise keinen Sinn, weil man sich damit unnötig beschränkt, es damit aber nicht einfacher ist (wenn nicht schon INI-Code da ist).

[Popov]

Wo beschränkt man sich? Wenn ich keine Großfamilie habe, dann kaufe ich mir auch nicht einen Kleinbus, weil da zehn Personen rein passen, ich also mehr Möglichkeiten habe. Natürlich ist/war TRegIniFile dazu gedacht einfach seine Ini umzuschreiben, aber was ist gegen

Delphi-Quellcode:

  with TRegIniFile.Create('Software\' + ChangeFileExt(ExtractFileName(ParamStr(0)), '')) do 
  try
    WriteString(Section, Ident, 'Irgendein Text')
  finally 
    Free 
  end;

zu sagen, wenn man einen String speichern möchte?

Ist es cooler für das gleiche Ergebnis doppelt so viele Zeilen zu nutzen, weil es TRegistry ist? Ja, wenn ich mehr speichern will, nutze ich auch TRegistry. Um Einstellungen zu speichern, da verbiege ich mich nicht künstlich, nur weil in der Hilfe steht, dass es für die Migration der alten INIs von Windows 3.x auf Windows 9x ist. Es ist da, es reicht für 98% alle Fälle, warum also mehr?

[himitsu]

Und wo ist da der große Unterschied zu dem?

Delphi-Quellcode:

with TRegistry.Create(KEY_WRITE) do
try
  OpenKey('Software\MeineFirma\MeinProgramm\' + Section, True);
  WriteString(Ident, 'Irgendein Text');
finally
  Free;
end;

Abgesehn daon, daß bei Beidem die Fehlerbehandlung fehlt.

[Popov]

Hast du jetzt geantwortet um nur um zu antworten oder war es ernst gemeint?

[jaenicke]

Zitat:

Zitat von Popov (Beitrag 1300439)

Wo beschränkt man sich? Wenn ich keine Großfamilie habe, dann kaufe ich mir auch nicht einen Kleinbus, weil da zehn Personen rein passen, ich also mehr Möglichkeiten habe.

Ich nehme aber auch keinen Transportbeutel für meine Fische nur weil sie da auch Wasser drin haben. Da bleibe ich lieber beim Aquarium.

Die meisten Programme werden im Laufe der Zeit erweitert und damit werden dann auch z.B. mehr Einstellungen usw. benötigt. Da ist es viel besser, wenn man gleich TRegistry benutzt hat und damit auch die Möglichkeit hat die Möglichkeiten der Registry auszuschöpfen.

Davon abgesehen sehe ich aber auch nicht den großen Unterschied im Quelltext, nur dass du bei TRegIniFile keinerlei Möglichkeit zur Fehlerbehandlung hast, da du nirgends den Rückgabewert von OpenKey im Konstruktor bekommst. Du weißt also nicht, ob du hinterher überhaupt schreiben kannst, kannst also nur auf eine Exception prüfen (oder CurrentPath gegenprüfen, aber naja)...

[Popov]

@jaenicke

Wenn du dir TRegIniFile genauer ansiehst, wirst du bemerken, dass es auf HKEY_CURRENT_USER beschränkt ist. Mit TRegIniFile kann man also nicht irgendwo anders schreiben, nur in HKEY_CURRENT_USER Zweig. Das ist die Einschränkung. Und auf HKEY_CURRENT_USER hat man in der Regel immer Rechte, da es dem CURRENT_USER, als dem aktuellen Benutzer gehört. Man greift also auf den eigenen Zweig der Registry zu. Somit sollte es keine Probleme geben.

Die Probleme die du meinst tauchen in der Regel in anderen Zweigen auf.

Ich könnte mir nur den einen Grund vorstellen, dass ein anderes Programm auf meine Einstellungen zugreift, was eigentlich nicht vorkommen sollt.

Also nochmal, allgemein auf die Registry zugreifen, da gebe ich dir Recht. Hier gehen es aber um HKEY_CURRENT_USER.

[Shark99]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1300402)

Nimm mal beim Pfad das führende Backslahs weg. Also Statt '\Software\Vendor\Productname' -> 'Software\Vendor\Productname'

Daran lag es nicht. Macht auch keinen Sinn, weil \ am Anfang die direkte Addressierung ist (kein Close des Keys zuvor notwendig). Ohne \ am Anfang ist der Key immer relativ zum gerade offenen Key (schon seit Delphi 3 und Windows 95).

Ich denke es liegt an was anderen. Ich hab auf der Kiste neben Delphi 7 und Delphi 2009 (Vollversionen) auch Delphi XE8 (30 Tage Trial). Kompiliere ich die Exe unter Delphi 7 und starte mit dem Explorer startet sie ohne Probleme. Aber sowohl unter 2009 als auch unter XE8 wenn ich die Exe über den Explorer starte kommt zuerst die Meldung 'The publisher could not be verified', was man sonst kennt wenn man eine Exe von einem Netzlaufwerk startet. Es ist aber hier alles lokal und zwar für alle 3 in c:\projects. Kopiere ich die Exes die von 2009 und XE8 erzeugt wurden woanders hin kommt die Meldung nicht mehr. Windows 7 mag also die von 2009 und XE8 erzeugten Exes nicht besonders und schränkt den Schreibzugriff auf die Registry, allerdings nur in dem Verzeichnis in dem sie kompiliert wurden.

Um die Theorie zu testen habe ich den Code leicht geändert:

Delphi-Quellcode:

FRegistry :=  TRegistry.Create(KEY_ALL_ACCESS OR KEY_WOW64_64KEY);
FRegistry.RootKey := HKEY_CURRENT_USER;
if FRegistry.OpenKey('\Software\Vendor\Productname', True) then
begin
   ShowMessage('ok');
end else
begin
   ShowMessage('not ok');
end;

Ergebnis:

Start aus c:\projects\project1: not ok
Nach Kopieren der Exe-Datei nach c:\test: ok

Also habe ich das Projekt nach c:\test\project1 verschoben. Starten -> ok. Wenn ich jedoch einen Rebuild mache und starte -> not ok.

Sehr sehr merkwürdige Sache. Ich denke es liegt irgendwie an meinem System. Ich verstehe aber nicht wieso die Exe wenn sie mit Delphi 7 kompiliert wird keinerlei Probleme macht. Vielleicht erkennt Windows 7 dass die Exe dann von einem Compiler ist der von der Era von vor Windows 7 stammt und gibt der Exe dann automatisch mehr Rechte (Kompatibilitätsmodus).

Trotzdem ist es extrem merkwürdig weil ich als Admin eingelogt bin und UAC komplett aus ist. 'Run as Administrator' ändert an der Sache nichts.

Bin wirklich mit meinem Latein am Ende. :roll:

[Dalai]

Schau mal genauer in folgende Registry-Zweige:

Code:

HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags
HKLM\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags
HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AppCompatFlags

ob dort deine EXE oder ähnliches mit Hinweis auf selbige auftaucht. Prüfe außerdem, ob die EXE an sich im Kompatibilitätsmodus läuft (Rechtsklick > Eigenschaften).

MfG Dalai

[Shark99]

Dalai, Danke für die Hinweise.

Im Kompabilitätsmodus (Windows XP3) direkt aus dem Projektverzeichnis kommt zwar OK, d.h. der Key wird gelesen, aber die App crasht dann sobald ein Schreibzugriff auf die Registry kommt (nach Umkopieren OK und kein Crash). Die Registry Keys werde ich gleich überprüfen.

[Shark99]

Habe alle AppCompatFlags Registry keys (inkl Subkeys) durchgeschaut, nichts dort zeigt auf die Exe oder c:\projects.

[p80286]

Zitat:

Zitat von Shark99 (Beitrag 1300460)

Ich verstehe aber nicht wieso die Exe wenn sie mit Delphi 7 kompiliert wird keinerlei Probleme macht. Vielleicht erkennt Windows 7 dass die Exe dann von einem Compiler ist der von der Era von vor Windows 7 stammt und gibt der Exe dann automatisch mehr Rechte (Kompatibilitätsmodus).

W7 ist um einiges jünger als d7 !

Zitat:

Zitat von Shark99 (Beitrag 1300460)

Trotzdem ist es extrem merkwürdig weil ich als Admin eingelogt bin und UAC komplett aus ist. 'Run as Administrator' ändert an der Sache nichts.

Nun ja!

vielleicht helfen Dir die Links weiter:
http://superuser.com/questions/34109...-network-files
http://www.technipages.com/disable-p...ified-messages

Gruß
K-H

[Shark99]

Zitat:

Zitat von p80286 (Beitrag 1300466)

vielleicht helfen Dir die Links weiter:
http://superuser.com/questions/34109...-network-files
http://www.technipages.com/disable-p...ified-messages

Gruß
K-H

Ich hab natürlich gegoogelt bis zum Umfallen (an die 4 Stunden). Hab aber sonst keinen Fall gefunden wo diese Publisher Nachricht auf einem lokalen Laufwerk kommt und zwar sogar dem Bootlaufwerk. Ich kenne es zur Genüge von Netzlaufwerken. Hab auch versucht die Gruppenlichtlinie zu ändern. Dann kommt die Warnung nicht mehr, das Problem bleibt aber.

[Popov]

Zitat:

Zitat von Shark99 (Beitrag 1300460)

Ich verstehe aber nicht wieso die Exe wenn sie mit Delphi 7 kompiliert wird keinerlei Probleme macht. Vielleicht erkennt Windows 7 dass die Exe dann von einem Compiler ist der von der Era von vor Windows 7 stammt und gibt der Exe dann automatisch mehr Rechte (Kompatibilitätsmodus).

Zum Thema EXE: Kann es sein, dass du die Exception still abfängst? Denn in der IDE bekommt man idR immer eine Meldung. Das bedeutet nicht, dass sie unter Exe nicht da ist (vorausgesetzt du hast sie abgefangen).

[Dalai]

Zitat:

Zitat von Shark99 (Beitrag 1300462)

Im Kompabilitätsmodus (Windows XP3) direkt aus dem Projektverzeichnis kommt zwar OK, d.h. der Key wird gelesen [...]

Ich meinte das andersrum: Kompat.modus ausschalten.

Kann es sein, dass du irgendeinen Virenscanner oder Internet Security verwendest, die da blockieren könnte? Testweise mal abschalten.

MfG Dalai

[Shark99]

Da ich derzeit Showmessage im Code habe spielen die Exceptions erstmals keine Rolle. Bei den Schreibzugriffen später (beim Beenden der ab) habe ich Try/Except blocks und die werden ausgelöst gefolgt vom Runtime Error 204.

[Shark99]

Zitat:

Zitat von Dalai (Beitrag 1300472)

Zitat:

Zitat von Shark99 (Beitrag 1300462)

Im Kompabilitätsmodus (Windows XP3) direkt aus dem Projektverzeichnis kommt zwar OK, d.h. der Key wird gelesen [...]

Ich meinte das andersrum: Kompat.modus ausschalten.

Kann es sein, dass du irgendeinen Virenscanner oder Internet Security verwendest, die da blockieren könnte? Testweise mal abschalten.

MfG Dalai

Der Kompat. Modus war doch aus. Dachte du meinst Einschalten.

Virenscanner (Nod32) habe ich natürlich Testweise schon abgeschaltet ohne Änderung.

[Dalai]

Noch eine andere Sache: Verwendest du ein Manifest? Wenn ja, wie sieht das aus? Gibt es Unterschiede in den Manifesten der unterschiedlichen Delphis?

[Shark99]

Verwende für das Projekt kein Manifest, weil die App keinerlei aussergewöhnliche Rechte braucht (Registry immer nur CURRENT_USER).

[Shark99]

Hab nun Testweise die Exe direkt im Projektverzeichnis digital signiert. Brachte leider keine Besserung.

[Dalai]

Zitat:

Zitat von Shark99 (Beitrag 1300479)

Verwende für das Projekt kein Manifest [...]

Und du bist sicher, dass in der EXE auch keines enthalten ist? Genau das ist der Knackpunkt.

[EDIT]
Wie heißt die EXE und in welchem Pfad liegt sie? Ich hatte selber mal ein Problem mit dem Kompatibilitätsmodus, der automatisch auf meine EXE angewendet wurde, vielleicht ist das hier auch der Fall.

MfG Dalai

[p80286]

Zitat:

Zitat von Shark99 (Beitrag 1300469)

Ich hab natürlich gegoogelt bis zum Umfallen (an die 4 Stunden). Hab aber sonst keinen Fall gefunden wo diese Publisher Nachricht auf einem lokalen Laufwerk kommt und zwar sogar dem Bootlaufwerk.

Dann hab Ich Dir etwas vorraus, bei mir kommt's auch von c:\irgendwas.
Aber mal was anderes wie sieht's denn mit dem Manifest aus?

Gruß
K-H

[Shark99]

Zitat:

Zitat von Dalai (Beitrag 1300483)

Zitat:

Zitat von Shark99 (Beitrag 1300479)

Verwende für das Projekt kein Manifest [...]

Und du bist sicher, dass in der EXE auch keines enthalten ist? Genau das ist der Knackpunkt.

[EDIT]
Wie heißt die EXE und in welchem Pfad liegt sie? Ich hatte selber mal ein Problem mit dem Kompatibilitätsmodus, der automatisch auf meine EXE angewendet wurde, vielleicht ist das hier auch der Fall.

MfG Dalai

Hattest Recht! Ein Manifest wurde eingebunden (ich habe das Projekt nicht erstellt und habe es übersehen). Wenn ich jedoch die Manifest.res wegkopiere, das Einbinden auskommentiere und einen Rebuild mache ändert sich nichts. Es kommt ein 'nicht ok'.

[Shark99]

Zitat:

Zitat von Dalai (Beitrag 1300483)

Wie heißt die EXE und in welchem Pfad liegt sie? Ich hatte selber mal ein Problem mit dem Kompatibilitätsmodus, der automatisch auf meine EXE angewendet wurde, vielleicht ist das hier auch der Fall.

MfG Dalai

Der Name der Exe spielt keine Rolle. Habe schon umbennen versucht und es ändert nichts an der Sache. Nur ein kopieren woandershin hilft. Auch ein wegkopieren, löschen, zurückkopieren bring nichts.

Ich habe aber etwas neues entdeckt!!

Wenn ich ein neues Verzeichnis anlege c:\delphitest, dorthin das projekt nach c:\delphitest\projektname kopiere und von dort kompiliere tritt der Fehler auf (also nicht OK). Wenn ich jedoch statt dessen in ein Verzeichnis kopiere welches schon vor langer Zeit angelegt wurde (getestet mit c:\temp und c:\a), so dass es in c:\a\projektname liegt kann ich dort kompilieren wie ich lustig bin und es kommen keine Fehler (immer ein OK und Schreibzugriffe funktionieren).

In anderen Worten mit meinem ArbeitsPC ist neulich was passiert dass die Zugriffsrechte in neu erstellten Verzeichnissen nicht mehr passen. Das ganze aber nur auf c:\

Wenn ich den ganzen Rotz von c:\ nach d:\ kopiere (D ist eine andere Partition auf der gleichen SSD) funktioniert alles wunderbar.

Ich mache mit PCs seit 25 Jahren rum, aber sowas habe ich noch nie erlebt (deshalb hilft ja Google nicht).

[himitsu]

Neuere Delphi erstellen das Manifest aus Daten in der DPROJ neu, wobei praktisch die komplette RES neu generiert wird, also durch Löschen der RES ändert sich nichts.

Neben dem Manifest hat sich auch Einiges am PE-Header geändert.


PS: Manifest Creator (OS-Kompatibilität usw.)

[BadenPower]

Zitat:

Zitat von Shark99 (Beitrag 1300460)

Delphi-Quellcode:

TRegistry.Create(KEY_ALL_ACCESS OR KEY_WOW64_64KEY);

Eventuell ein 32/64-Bit-Systemproblem in Punkto Rechtevergabe?

http://www.delphipraxis.net/86651-re...w6432node.html


Gib einfach einmal
TRegistry.Create(KEY_ALL_ACCESS OR KEY_WOW64_64KEY);
bei Google ein, da kommt massenweise Lesestoff.

Ob eine Lösung dabei ist, kann ich Dir leider nicht garantieren.

[Dalai]

Zitat:

Zitat von Shark99 (Beitrag 1300489)

In anderen Worten mit meinem ArbeitsPC ist neulich was passiert dass die Zugriffsrechte in neu erstellten Verzeichnissen nicht mehr passen. Das ganze aber nur auf c:\

Was haben denn die Zugriffsrechte mit dem Problem zu tun? Entweder die EXE wird ausgeführt oder nicht. Dazwischen gibt es nichts.

Zitat:

Wenn ich den ganzen Rotz von c:\ nach d:\ kopiere (D ist eine andere Partition auf der gleichen SSD) funktioniert alles wunderbar.

Ich glaube hier immer noch an einen Eintrag in der Kompatibilitätsdatenbank. Ich schlage daher vor, dass du dir die DB mal genauer anschaust, und zwar mit dem Compatibility Administrator, der im Application Compatibility Toolkit enthalten ist. Damit öffnest du die Systemdatenbank (sysmain.db) und suchst dort nach dem Pfad oder anderen Angaben, die auf deine EXE passen.

MfG Dalai

[Shark99]

Zitat:

Zitat von Dalai (Beitrag 1300494)

]Ich glaube hier immer noch an einen Eintrag in der Kompatibilitätsdatenbank. Ich schlage daher vor, dass du dir die DB mal genauer anschaust, und zwar mit dem Compatibility Administrator, der im Application Compatibility Toolkit enthalten ist. Damit öffnest du die Systemdatenbank (sysmain.db) und suchst dort nach dem Pfad oder anderen Angaben, die auf deine EXE passen.

MfG Dalai

Das glaube ich nicht. Wieso hat dann jedes neuangelegte Verzeichnis das Problem, aber keines von denen die angelegt waren bevor ich das Problem bemerkte? Übrigens auch ein leeres Projekt (nur Fenster) hat das 'Publisher not verified' Problem sobald es aus einem neu angelegten Verzeichnis kompiliert wird.

[Shark99]

Zitat:

Zitat von BadenPower (Beitrag 1300493)

Eventuell ein 32/64-Bit-Systemproblem in Punkto Rechtevergabe?

Ich hab schon alle Kombination durch. Das Problem kommt immer. Hängt ja auch gar nicht vom Code ab, sondern in welchen Verzeichnis der Code kompiliert wird. Schiebe ich das Projekt in in das Verzeichnis der Delphi-7 Projekte (welches vor 5 Jahren angelegt wurde) geht alles wunderbar und zwar auch wenn ich nur TRegistry.Create ohne Parameter aufrufe!

Ich denke also es ist kein Delphi-Problem per SE, sondern es ist mit meinem ArbeitsPC etwas nicht in Ordnung (Richtlinien oder Registry) und alle neu angelegten Verzeichnisse auf c:\ haben stark eingeschränkte Rechte (d:\ hat das Problem nicht).

[Dalai]

Zitat:

Zitat von Shark99 (Beitrag 1300503)

Übrigens auch ein leeres Projekt (nur Fenster) hat das 'Publisher not verified' Problem sobald es aus einem neu angelegten Verzeichnis kompiliert wird.

Dieses Problem würde ich erstmal völlig außen vor lassen, denn ich glaube nicht, dass es hier einen direkten Zusammenhang gibt.

Zitat:

Ich denke also es ist kein Delphi-Problem per SE, sondern es ist mit meinem ArbeitsPC etwas nicht in Ordnung (Richtlinien oder Registry) und alle neu angelegten Verzeichnisse auf c:\ haben stark eingeschränkte Rechte (d:\ hat das Problem nicht).

Naja, nichts leichter als das zu prüfen, oder? Aber wie gesagt: Entweder eine Datei bzw. ein Verzeichnis hat das Recht, ausgeführt zu werden oder sie/es hat es nicht. Bei den NTFS-Zugriffsrechten gibt's da nichts weiter.

Aber da du gerade nochmal die Geschichte mit den Pfaden erwähnst, fällt mir etwas ein: Die Sache mit dem "Publisher not verified" kommt direkt vom IE bzw. dessen Sicherheitszonen. Vielleicht hat sie doch etwas damit zu tun, weil evtl. (Programme aus) bestimmte(n) Zonen keine Rechte haben, auf bestimmte Registry-Zweige zuzugreifen - kann ich mir jedenfalls vorstellen.

Schau mal in der Systemsteuerung > Internetoptionen > Register Sicherheit, ob unter Eingeschränkte Sites etwas eingetragen ist. Ggf. hilft es auch, die Zonen alle auf Standard zurückzustellen (Button unten in der genannten Registerkarte).

MfG Dalai

[Shark99]

Hab alle Zonen resettet (+Reboot). Hat leider nichts gebracht.

[Dalai]

Schau dir mal die NTFS ADS der problematischen Dateien und Verzeichnisse an. Das geht z.B. mit AlternateStreamView. Vielleicht sagen die etwas darüber, dass die Datei aus einer anderen Zone stammt.

MfG Dalai

[Popov]

Eine kleine Bitte. Teste mal die drei Zeilen

Delphi-Quellcode:

  with TRegIniFile.Create('Software\Vendor\Productname') do try
    WriteString('', 'Test', 'Testwert');
  finally Free end;

Hier übernimmt im Grunde Delphi das Drumherum und öffnet die Keys. Ist es eine Frage der Rechte, dürfte der Dreizeiler nichts in den Pfad schreiben. Denn ob du keine Rechte bekommst oder der Dreizeiler, ist ja das Gleiche. Schreibt er hingegen etwas in den Pfad rein, weißt du, dass der Fehler im Code liegt.


Bei der Gelegenheit würde ich gerne die Frage stellen ob du evtl. schon vorher, also vor den Zeilen einmal auf die Registry zugegriffen hast? Das ist nicht unwichtig.

Ich kann mich nicht mehr genau dran erinnern woran es lag, ich glaube es lag an fehlendem CloseKey, da hatte ich ein ähnliches Problem. Damals habe ich irgendwo in der Hilfe gelesen (das finde ich jetzt nicht mehr), dass es sehr wichtig ist, dass der Schlüssel wieder geschlossen wird, weil sonst... irgendwas nicht richtig funktionieren wird.

Wie gesagt, ich finde die Zeilen jetzt nicht wieder. Aber wichtig für dich ist - schließt du auch immer schön den Schlüssel wieder?


EDIT:

Der Ablauf sollte in etwas so aussehen:

Delphi-Quellcode:

var
  Reg: TRegistry;
begin
  Reg := TRegistry.Create;
  try
    Reg.RootKey := HKEY_CURRENT_USER;
    if Reg.OpenKey('\Software\Usw', True) then
    begin
      Reg.WriteString('Bla','Blabla');
      Reg.CloseKey; //wird gerne vergessen
    end;
  finally
    Reg.Free;
  end;
end;

[jaenicke]

Zitat:

Zitat von Popov (Beitrag 1300513)

Damals habe ich irgendwo in der Hilfe gelesen (das finde ich jetzt nicht mehr), dass es sehr wichtig ist, dass der Schlüssel wieder geschlossen wird, weil sonst... irgendwas nicht richtig funktionieren wird.

Ein weiteres OpenKey, weil das dann relativ zum bereits offenen Schlüssel läuft. Sprich OpenKey auf Software, dann OpenKey auf Software\Microsoft öffnet Software\Software\Microsoft, wenn der erste Key nicht vorher geschlossen wurde.

[Shark99]

Zitat:

Zitat von Dalai (Beitrag 1300511)

Schau dir mal die NTFS ADS der problematischen Dateien und Verzeichnisse an. Das geht z.B. mit AlternateStreamView. Vielleicht sagen die etwas darüber, dass die Datei aus einer anderen Zone stammt.

MfG Dalai

Hab das Projekt auf Fat32 Partition umkopiert, Verzeichnis gelöscht, zurück auf NTFS, keine Änderungen.