Registry: Typ ermitteln

[Pseudemys Nelsoni]

moin,

gibt es eine funktion der winapi mit der ich den typ eines keynamens bekomme? bei funktionen wie RegQueryValueEx übergibt man ja den typ, aber ich hab noch keine gesehen mit der man den typ bekommt.
Also mit typ meine ich z.b REG_SZ usw

[Phoenix]

Erm... Bei RegQueryValueEx bekommst Du den Typ zurück. Du übergibst ihn nicht.

Alternativ kannst Du auch mit RegEnumValue alle Namen der Values incl. deren Typ zurückgeben lassen.

[MathiasSimmack]

Na klar, du übergibst als Typ REG_NONE, und erhältst im Gegenzug dafür den richtigen Typ geliefert. Ich habe dir, @Pseudemys Nelsoni, gestern (?) den Link zu einem DF-Beitrag gegeben, und in den Tutorials wird auch vorgemacht, wie man den Typ ermittelt. Und gerade eben habe ich auch was dazu bei deinem Exception-Beitrag geschrieben.


Edit: Name ergänzt, weil sich Phoenix reingedrängelt hat.

[Pseudemys Nelsoni]

Zitat:

Na klar, du übergibst als Typ REG_NONE, und erhältst im Gegenzug dafür den richtigen Typ geliefert.

hallo mathias, mich hat nur das hier stutzig gemacht:

Zitat von PSDK:

lpType
[out] Pointer to a variable that receives a code indicating the type of data stored in the specified value. For a list of the possible type codes, see Registry Value Types. The lpType parameter can be NULL if the type code is not required.

also weil da "out" und nicht "in" steht, deswegen wunder ich mich wieso man denn da den typ doch(ß) bekommt.

[Muetze1]

Moin!

Zitat von Pseudemys Nelsoni:

also weil da "out" und nicht "in" steht, deswegen wunder ich mich wieso man denn da den typ doch(ß) bekommt.

Na die Funktion will einen Zeiger auf einen Speicherplatz haben wo sie die Information ablegen kann. Und sie gibt diese Informationen zurück, daher out. In bedeutet ja, dass die Funktion diesen Parameter beim Aufruf benötigt und dieser "reingegeben" werden muss, out, das dieser "herausgegeben" wird (bzw. zurück gegeben).

MfG
Muetze1

[Pseudemys Nelsoni]

ok, dann noch eine frage dazu. Ich habe folgendes(nur das wichtigste daraus) aus den Win32api tut sources von luckie:

Delphi-Quellcode:

function Reg_ReadString(const RootKey: HKEY; const RegVal: string): string;
var
  lpType: DWORD;
begin
  lpType := REG_NONE;

  if(RegQueryValueEx(RootKey,@RegVal[1],nil,@lpType,nil,@cbData) =
       ERROR_SUCCESS) .....

wieso wird lpType denn auf REG_NONE gesetzt wenn die funktion "RegQueryValueEx" sowieso nicht daraus liest?

[MathiasSimmack]

Evtl. wäre es ja denkbar, dass das Auslesen des Typs mal nicht klappt. In dem Fall hätte die Variable dann auch keinen Wert. So aber setzt du vorher REG_NONE, und es dürfte/wird beim Vergleich bzw. bei der Typprüfung überhaupt keine Probleme geben.

(btw: Das ist meine Meinung. Sollte die falsch sein, schiebe ich den schwarzen Peter an NicoDE weiter, von dem nämlich die Funktion stammt, durch die ich das allererste Mal Kontakt mit der Registry auf API-Ebene erhielt. )

[Phoenix]

Ich habe inzwischen eine ziemlich komplette Übersetzung der gesamten Registry-Funktionen für Delphi selber gemacht. Es ist tatsächlich so, das unter ganz widrigen Umständen der Wert von Type undefiniert ist.

Ist er aber initialisiert, so wird er auch nicht geändert - demnach kann man hier dann sauber weiterarbeiten ohne gefahr zu laufen, zufällig einen gültigen Wert drin stehen zu haben, der dann aber nicht passt.

[NicoDE]

Zitat von MathiasSimmack:

(btw: Das ist meine Meinung. Sollte die falsch sein, schiebe ich den schwarzen Peter an NicoDE weiter, von dem nämlich die Funktion stammt )

Ich habe zu oft erlebt, dass Funktionen bei nicht initialisierten Werten, deren Inhalt laut Dokumentation ignoriert werden sollte, nicht das tun was man erwartet hat.
Ist also einfach eine alte Angewohnheit, die ich, trotz teilweiser Sinnlosigkeit bzw. dem Anschein von Verfolgungswahn, nicht geneigt bin wieder abzulegen
(es kann unter Win9x zu einem Crash kommen, wenn man TLVItems nicht mit Nullen füllt, obwohl die Werte laut Flags ignoriert werden sollten... um nur ein Beispiel zu nennen)

[MathiasSimmack]

@Nico, Phoenix: Also war meine Vermutung richtig.