Delphi-PRAXiS
Seite 4 von 10   « Erste     234 56     Letzte »    

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Win32/Win64 API (native code) (https://www.delphipraxis.net/17-win32-win64-api-native-code/)
-   -   TRegistry Unterschied zwischen Delphi 7 und 2009 (https://www.delphipraxis.net/184986-tregistry-unterschied-zwischen-delphi-7-und-2009-a.html)

BadenPower 6. Mai 2015 17:36

AW: TRegistry Unterschied zwischen Delphi 7 und 2009
 
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 6. Mai 2015 17:37

AW: TRegistry Unterschied zwischen Delphi 7 und 2009
 
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 6. Mai 2015 18:56

AW: TRegistry Unterschied zwischen Delphi 7 und 2009
 
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 6. Mai 2015 19:00

AW: TRegistry Unterschied zwischen Delphi 7 und 2009
 
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 6. Mai 2015 19:10

AW: TRegistry Unterschied zwischen Delphi 7 und 2009
 
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 6. Mai 2015 19:45

AW: TRegistry Unterschied zwischen Delphi 7 und 2009
 
Hab alle Zonen resettet (+Reboot). Hat leider nichts gebracht.

Dalai 6. Mai 2015 20:03

AW: TRegistry Unterschied zwischen Delphi 7 und 2009
 
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 6. Mai 2015 20:10

AW: TRegistry Unterschied zwischen Delphi 7 und 2009
 
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 6. Mai 2015 20:36

AW: TRegistry Unterschied zwischen Delphi 7 und 2009
 
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 6. Mai 2015 21:48

AW: TRegistry Unterschied zwischen Delphi 7 und 2009
 
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.


Alle Zeitangaben in WEZ +1. Es ist jetzt 03:23 Uhr.
Seite 4 von 10   « Erste     234 56     Letzte »    

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz