Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Probleme avec RegQueryValueEx

4 réponses
Avatar
Zorro
Bonjour, voici un morceau de code (la clé hKey a été ouverte avec succés au
préalable et les 3 valeurs dans cette clé qui sont lues existent et son bien
définies avec le type voulu):

LONG a;
a=RegQueryValueEx(hKey,TEXT("ValUn"),0,NULL,tpbuf,&dwSize);
if (a!=ERROR_SUCCESS)
RegQueryValueEx(hKey,TEXT("ValUn"),0,NULL,tpbuf,&dwSize);
if (a!=ERROR_SUCCESS) // la valeur n'est pas accessible
else // on utilise la première valeur

a=RegQueryValueEx(hKey,TEXT("ValDeux"),0,NULL,tpbuf,&dwSize);
if (a!=ERROR_SUCCESS)
a=RegQueryValueEx(hKey,TEXT("ValDeux"),0,NULL,tpbuf,&dwSize);
if (a!=ERROR_SUCCESS) // la valeur n'est pas accessible
else // on utilise la deuxième valeur

a=RegQueryValueEx(hKey,TEXT("ValTrois"),0,NULL,tpbuf,&dwSize);
if (a!=ERROR_SUCCESS)
a=RegQueryValueEx(hKey,TEXT("ValTrois"),0,NULL,tpbuf,&dwSize);
if (a!=ERROR_SUCCESS) // la valeur n'est pas accessible
else // on utilise la troisième valeur

Ce code marche parfaitement, mais comme vous le voyez je suis obligé de
faire 2 fois appel à RegQueryValueEx à chaque fois. Dans mon cas, si je ne
fais appel qu'une fois à RegQueryValueEx, cet appel pour la deuxième valeur
me renvoit un code 234L (donc ERROR_MORE_DATA, alors que la variable tpbuf
fait 256 char de long et la valeur lue 23 et surtout que ça marche la
deuxième fois) avec tpbuf contenant les valeurs 1, 0, 0,... En plus il n'ya
aucune raison que ça marche plus pour la 3° valeur que pour la 2° car elles
sont absolument créées dans les mêmes conditions (même type, etc... à part
la longueur).

Merci de votre assistance

David

4 réponses

Avatar
Thierry
Bonjour,

Zorro a écrit :

[SNIP]

En jetant vite un oeil je dirais que t'oublie juste de remettre dwSize a la
valeur effective de la taille de ton buffer avant chaque appel a
QueryValue.


--
« Le travail est probablement ce qu'il y a sur cette terre de plus bas et
de plus ignoble. Il n'est pas possible de regarder un travailleur sans
maudire ce qui a fait que cet homme travaille, alors qu'il pourrait nager,
dormir dans l'herbe ou simplement lire ou faire l'amour avec sa femme. »
Boris VIAN
Mon blog RSS : http://yarglah.free.fr/monblog_rss.php <<




Avatar
Zorro
Pourquoi il faut? je pensais que QueryValue ne fait que mettre une valeur
dans dwSize et non pas lire son contenu (qui est changeant et que je ne peut
déterminer à l'avance qu'en fait un premier appel à QueryValue). Et comment
se fait il que ça marchait avant pour la troisième valeur? La 2° et la 3°
valeurs sont des REG_SZ de valeur irrégulière.
Merci
"Thierry" a écrit dans le message de
news:
Bonjour,

Zorro a écrit :

[SNIP]

En jetant vite un oeil je dirais que t'oublie juste de remettre dwSize a


la
valeur effective de la taille de ton buffer avant chaque appel a
QueryValue.


--
« Le travail est probablement ce qu'il y a sur cette terre de plus bas et
de plus ignoble. Il n'est pas possible de regarder un travailleur sans
maudire ce qui a fait que cet homme travaille, alors qu'il pourrait nager,
dormir dans l'herbe ou simplement lire ou faire l'amour avec sa femme. »
Boris VIAN
>> Mon blog RSS : http://yarglah.free.fr/monblog_rss.php <<


Avatar
Clément
"Zorro" a écrit dans le message de news:
42e8c98a$0$14289$
Pourquoi il faut? je pensais que QueryValue ne fait que mettre une valeur
dans dwSize et non pas lire son contenu (qui est changeant et que je ne
peut
déterminer à l'avance qu'en fait un premier appel à QueryValue).



lpcbData
[in, out] Pointer to a variable that specifies the size of the buffer
pointed to by the lpData parameter, in bytes. When the function returns,
this variable contains the size of the data copied to lpData.

-> entrée ET sortie.

Si tu ne peux pas prévoir la taille maximale de ta valeur, fais un 1er appel
avec dwSize = 0, ensuite dwSize contiendra la bonne valeur -> tu pourras
faire une allocation dynamique de juste la taille qu'il faut.

Et comment
se fait il que ça marchait avant pour la troisième valeur? La 2° et la 3°
valeurs sont des REG_SZ de valeur irrégulière.



Peut-etre que la 3e etait plus petite que la 2e, donc dwSize (renvoyé par
l'appel pour la 2e valeur) était assez grand.

Clément
Avatar
Zorro
Merci beaucoup à vous 2
David
"Clément" a écrit dans le message de
news:42e8d77b$0$30293$

"Zorro" a écrit dans le message de news:
42e8c98a$0$14289$
> Pourquoi il faut? je pensais que QueryValue ne fait que mettre une


valeur
> dans dwSize et non pas lire son contenu (qui est changeant et que je ne
> peut
> déterminer à l'avance qu'en fait un premier appel à QueryValue).

lpcbData
[in, out] Pointer to a variable that specifies the size of the buffer
pointed to by the lpData parameter, in bytes. When the function returns,
this variable contains the size of the data copied to lpData.

-> entrée ET sortie.

Si tu ne peux pas prévoir la taille maximale de ta valeur, fais un 1er


appel
avec dwSize = 0, ensuite dwSize contiendra la bonne valeur -> tu pourras
faire une allocation dynamique de juste la taille qu'il faut.

> Et comment
> se fait il que ça marchait avant pour la troisième valeur? La 2° et la



> valeurs sont des REG_SZ de valeur irrégulière.

Peut-etre que la 3e etait plus petite que la 2e, donc dwSize (renvoyé par
l'appel pour la 2e valeur) était assez grand.

Clément