Odczyt danych z rejestru pod Win7 64bit

Witam, mam problem z odczytem wartości z rejestru systemowego.
Mogę zapisywać/usuwać klucze w rejestrze(win7 64bit), ale nie mogę odczytywać. Uruchamiałem program także jako admin.
oto moje próby, próbowałem różnie stąd komentarze do kodu:

 const
  REGKEY = '\Software\Microsoft\Windows\CurrentVersion\Run';
var
  Registry: TRegistry;
begin
  Result := False;

//  Registry := TRegistry.Create(KEY_READ or $0100);
  Registry := TRegistry.Create(KEY_READ);
  try
    Registry.RootKey := HKEY_CURRENT_USER;
    if Registry.OpenKeyReadOnly(REGKEY) then
//    if Registry.OpenKey(REGKEY, False) then
    begin
//      Registry.Access := KEY_READ; // or KEY_WOW64_64KEY;
      Result := Registry.ValueExists(AppName);
      ShowMessage(Registry.ReadString(AppName));
//      Result := Registry.KeyExists(AppName);
    end;
  finally
    Registry.Free;
  end;
end;

Pytanie brzmi jak odczytać coś z rejestru na tych nowszych systemach :)

Nie mam jak sprawdzić kodu w tej chwili. Ale pogoogluj za przykładami użycia TRegIniFile. Nie wiem też czy powinien być ten backslash na początku ścieżki.

IMHO nie powinno być wiodącego backslasha i pewnie to jest główną przyczyną problemów, bo skoro Drut może tworzyć i usuwać klucze, to ma raczej pełne uprawnienia; Zresztą nawet jeśli uprawnienia były by ograniczone, to odczytywać dane z rejestru i tak by mógł; W każdym razie można sprawdzić;

Jeżeli o program pisany w Delphi 7 chodzi, to ten wątek może pomóc.

Dodam, że chodzi o XE5, ale to raczej może być kwestia systemu.... w każdym razie próbowałem różnych ustawień. Proszę o pomoc jeśli ktoś ma możliwość sprawdzenia u siebie.

U mnie na Windows 7 64bit powyższy kod działa zarówno kompilowany w Delphi 7 i XE7 (w innych nie mam możliwości sprawdzić). Oczywiście mimo że UAC włączony to program NIE WYMAGA praw admina, bo po pierwsze tylko odczytujemy a po drugie działamy na HKEY_CURRENT_USER a tu nawet jako user można otworzyć klucz do odczytu i do zapisu.

@Drut Stalowy - struktura Twojego algorytmu jest trochę dziwna, bo robisz dwie sprzeczne rzeczy; Jeśli da się otworzyć klucz i pobrać wartość, to należy zwrócić True i wywołać ShowMessage, a w każdym innym przypadku zwrócić False;

Większy sens miałoby zapisanie tego w ten sposób;

const
  REGKEY = '\Software\Microsoft\Windows\CurrentVersion\Run';
begin
  with TRegistry.Create(KEY_READ) do
  try
    RootKey := HKEY_CURRENT_USER;

    if OpenKeyReadOnly(REGKEY) then
    try
      if ValueExists(AppName) then
      begin
        ShowMessage(ReadString(AppName));
        Result := True;
      end
      else
        Result := False;
    finally
      CloseKey();
    end
    else
      Result := False;
  finally
    Free();
  end;
end;

Jeżeli wiadomość nie pokazuje się, to wartość musi nieistnieć w rejestrze; Nie wiem czym jest i co zawiera AppName, w każdym razie sprawdź jej zawartość pod debugerem i zobacz, czy wartość we wspomnianym kluczu faktycznie istnieje.

OK, zaczęło działać, po prostu dziś włączyłem kompa oraz aplikację(nie z poziomu IDE) i zaczęło chwytać...
Kod wygląda tak:

 
const
  REGKEY = '\Software\Microsoft\Windows\CurrentVersion\Run';
var
  Registry: TRegistry;
begin
  Result := False;

  Registry := TRegistry.Create(KEY_READ);
  try
    Registry.RootKey := HKEY_CURRENT_USER;
    if Registry.OpenKeyReadOnly(REGKEY) then
    begin
      Result := Registry.ValueExists(AppName);
    end;
  finally
    Registry.Free;
  end;
end;

PS. Nie jestem zwolennikiem Ifów zbytecznych - ustawianie wyniku na False na początku jest proste i skuteczne.

PS. Nie jestem zwolennikiem Ifów zbytecznych - ustawianie wyniku na False na początku jest proste i skuteczne.

Może i tak, jednak w Twoim kodzie ten If i tak jest zbyteczny :]

Nie potrzebujesz zmiennej, a dodatkowo z racji specyfiki działania warunków, kod możesz skrócić do poniższej postaci:

const
  REGKEY = '\Software\Microsoft\Windows\CurrentVersion\Run';
begin
  with TRegistry.Create(KEY_READ) do
  try
    RootKey := HKEY_CURRENT_USER;
    Result  := OpenKeyReadOnly(REGKEY) and ValueExists(AppName);
  finally
    Free();
  end;
end;

Żadnego inicjowania, żadnych **If**ów, a także żadnych ostrzeżeń i zawsze prawidłowy rezultat.

A po co tam to takie:

TRegistry.Create(KEY_READ)

niby co tu tworzymy - zmienną na stosie?

Bardzo zabawne... te TRegi z delfina. lol)

dodanie znacznika <code class="delphi"> - @furious programming

TRegistry.Create(KEY_READ)

niby co tu tworzymy - zmienną na stosie?

Czego nie rozumiesz? Przecież to zwykłe wywołanie konstruktora;

Opisując całość - tworzymy obiekt klasy TRegistry, do którego referencję "przechowa" instrukcja wiążąca; Chyba nie muszę Ci tłumaczyć, że każdy konstruktor każdej klasy to tak naprawdę niejawna funkcja, która zwraca niejawny wskaźnik na obiekt; Dodatkowo, w przypadku takiej konstrukcji, blok Try Finally jest konieczny, aby móc zawsze bezpiecznie zwolnić obiekt;

Podany przeze mnie kod jest krótszy i zawiera mniej instrukcji (co sprawia że jest szybszy); A Ty jak czegoś nie rozumiesz to pytaj normalnie, bez rzucania "lol-ami" rodem z tibiowskiej gimbazy.

Bardzo dobrze, ale taki kluczyk do rejestru to przecież nie żaden obiekt, a broń boże classer,
lecz zwyczajny numerek... HKEY, czyli jakieś zwykłe int, i nic poza tym, więc nie wiem tu miałoby się tworzyć.

Dla mnie to typowy przerost formy nad treścią, czyli strzelanie do komara z rury fi 40''.

Bardzo dobrze, ale taki kluczyk do rejestru to przecież nie żaden obiekt, a broń boże classer,
lecz zwyczajny numerek...

A kogo obchodzi fizyczna reprezentacja rejestru i jego zawartości?

HKEY, czyli jakieś zwykłe int, i nic poza tym, więc nie wiem tu miałoby się tworzyć.

Nie wiesz co się tworzy, bo zwyczajnie nie masz zielonego pojęcia o programowaniu obiektowym w Delphi; Więc albo zacznij sobie przyswajać wiedzę z tego tematu, albo nie wypowiadaj się w ogóle;

Dla mnie to typowy przerost formy nad treścią, czyli strzelanie do komara z rury fi 40''.

OOP to niby przerost formy nad treścią? W takim razie pisz sobie w gołym WinAPI, koniecznie ze wstawkami asma, bo nie daj Boże plik urośnie o pare kilobajtów i dysk Ci się przepełni.

furious programming napisał(a):

Bardzo dobrze, ale taki kluczyk do rejestru to przecież nie żaden obiekt, a broń boże classer,
lecz zwyczajny numerek...

A kogo obchodzi fizyczna reprezentacja rejestru i jego zawartości?

Może np. zawodowego programistę to zainteresuje, albo przynajmniej powinno... nie/tak/irrelevant?

furious programming napisał(a):

Nie wiesz co się tworzy, bo zwyczajnie nie masz zielonego pojęcia o programowaniu obiektowym w Delphi; Więc albo zacznij sobie przyswajać wiedzę z tego tematu, albo nie wypowiadaj się w ogóle;

A to dlaczego tak od razu miałbym nie wiedzieć, skoro np. źródło tego TRegisty mogę sobie wylistować na... srebrnym ekranie?

furious programming napisał(a):

OOP to niby przerost formy nad treścią? W takim razie pisz sobie w gołym WinAPI, koniecznie ze wstawkami asma, bo nie daj Boże plik urośnie o pare kilobajtów i dysk Ci się przepełni.

A niby po co miałbym od razu tak pisać... chociaż przyznam, że są assemblerowcy,
którzy dokładnie tak programują, no i oczywiści nie mają tych wszystkich problemów,
których świat nigdy by nie doznał ani poznał, gdyby nie te twoje rewelacyjne odkrycia programistyczne...
zwłaszcza w dziedzinie try... finally. lollllllll).

Może np. zawodowego programistę to zainteresuje, albo przynajmniej powinno... nie/tak/irrelevant?

Taa, szczególnie dlatego, że zawodowcy mają za dużo wolnego czasu w pracy i mogą go marnować na przepisywanie VCL...

A to dlaczego tak od razu miałbym nie wiedzieć, skoro np. źródło tego TRegisty mogę sobie wylistować na... srebrnym ekranie?

Wylistować a zrozumieć to dwie skrajnie różne rzeczy;

chociaż przyznam, że są assemblerowcy, którzy dokładnie tak programują,

Aplikacje desktopowe? A może gry? Jeśli tak, to co najwyżej u siebie w domu, bo VCL wymyślono po to, aby nie marnować czasu na pisanie setek jak nie tysięcy linii kodu, aby zbudować interfejs formularza;

no i oczywiści nie mają tych wszystkich problemów, których świat nigdy by nie doznał ani poznał, gdyby nie te twoje rewelacyjne odkrycia programistyczne...

Moje odkrycia? Ty w ogóle zastanawiasz się nad tym co piszesz, czy radośnie walisz w klawiaturę, bo nie masz nic ciekawszego do roboty? Rację miałem - przyszedłeś jedynie potrolować, bo wartość merytoryczna Twoich wypocin jest żadna;

A może chciałeś się pochwalić, że wygooglowałeś sobie fizyczną strukturę rejestru? Naprawdę gratuluję - googluj dalej.

furious programming napisał(a):

Taa, szczególnie dlatego, że zawodowcy mają za dużo wolnego czasu w pracy i mogą go marnować na przepisywanie VCL...

Niby po co miałby ktoś przepisywać te dziecinne ćwiczenia w programowaniu obiektowym?

chociaż przyznam, że są assemblerowcy, którzy dokładnie tak programują,

Aplikacje desktopowe? A może gry? Jeśli tak, to co najwyżej u siebie w domu, bo VCL wymyślono po to, aby nie marnować czasu na pisanie setek jak nie tysięcy linii kodu, aby zbudować interfejs formularza;</quote>

Jakiego formularza?
To się robi zwyczajne - w edytorze dialogów, ikon, i innych drobiazgów: tzw. resource workshop.

Nie wiem po co miałbym powielać to w delfinie, czy innym szajsie z trzeciej ręki...
no chyba że w celu powiększenia programu, spowolnienia działania, no i ogólnego zrypania wyglądu.

furious programming napisał(a):

Moje odkrycia? Ty w ogóle zastanawiasz się nad tym co piszesz, czy radośnie walisz w klawiaturę, bo nie masz nic ciekawszego do roboty? Rację miałem - przyszedłeś jedynie potrolować, bo wartość merytoryczna Twoich wypocin jest żadna;

Przestań pajacować.
Każdy szmaciarz wie po co wyprodukowano te... kichy pt. delphi, i inne podobne.

Dla dzieci... do zabawy w programowanie. :)

To się robi zwyczajne - w edytorze dialogów, ikon, i innych drobiazgów: tzw. resource workshop.

W edytorze dialogów dla WinAPI zrobisz tylko wygląd (część wyglądu), kodu trzeba sporo pisać. Przy drugim-trzecim oknie podczas pisania znowu tych samych linijek człowiek zaczyna się zastanawiać, czy nie wyciągnąć wspólnego kodu do jakiejś klasy, oprogramować zdarzenia... i tak powstaje nowy, bieda-VCL ;-)

Azarien napisał(a):

To się robi zwyczajne - w edytorze dialogów, ikon, i innych drobiazgów: tzw. resource workshop.

W edytorze dialogów dla WinAPI zrobisz tylko wygląd (część wyglądu), kodu trzeba sporo pisać. Przy drugim-trzecim oknie podczas pisania znowu tych samych linijek człowiek zaczyna się zastanawiać, czy nie wyciągnąć wspólnego kodu do jakiejś klasy, oprogramować zdarzenia... i tak powstaje nowy, bieda-VCL ;-)

A co sugerujesz znowu... że niby potrafisz coś zaprogramować bez programowania w ogóle, czy jak?

Robiłem po kilkadziesiąt takich dialogów (waszych form) w jednej aplikacji,
no i nie wiedzę tam nawet cienia szans załatwienia tego za pomocą jednego schematu, a zwłaszcza delfinowatego.

Np. w jednym takim dialogu masz 1 string do wczytania, ale w drugim jest raptem z 40 parametrów,
i w tym niektóre mogą być z podrzędnych dialogów.

Zapewne obiektowość go przerasta, dlatego biedak morduje się w WinAPI i siłą rzeczy twierdzi, że nie ma nic lepszego; - furious programming dzisiaj, 00:34

A gdzie ty widziałeś obiektowość w tym delphi, a zwłaszcza w tych vcl?

Oblektowym jest np. c++, gdzie są autokonstruktory, destruktory, dziedziczenie z wielu class... ładowane operatory, itd.

Delphi to zaledwie namiastka;
ty ustawianie adresu funkcji: Onclick, OnPing, ect... nazywasz programowaniem obiektowym. :)