vb6: accéder aux valeurs du registre

Question

J'écris un simple bouton vb6 qui teste l'accès aux valeurs du registre.

je les suivantes:

Private Function registry_read(key_path, key_name) as variant 

Dim registry as object 
set registry = CreateObject("WScript.shell") 
registry_read = registry.regread(key_path & key_name) 
End function 

Private Sub Command1_Click() 
MsgBox registry_read("HKEY_LOCAL_MACHINE\SOFTWARE\PROCESS\frmMain_Values\", "Version") 
end Sub 

J'ai Menu Projet -> Références et sélectionnez Microsoft WMI Scripting V1.1 Bibliothèque sélectionné et Windows Script Object Model hôte référencé

mais mon msgbox est toujours à venir vide. J'ai vérifié le chemin du registre et c'est correct. des idées?

merci d'avance.

Answer 1

Vous devez commenter la ligne 'sur erreur reprendre ensuite' pendant que vous développez. Si une erreur se produit, vous ne pourrez pas voir les détails. Il peut s'agir de not found ou access denied etc.

Il existe également deux façons de référencer un objet. Liaison précoce, c'est-à-dire Dim rs as new adobdb.recordset et liaison tardive set rs = CreateObject("Adodb.recordset"). La première méthode (liaison anticipée) vous oblige à déclarer une référence et la seconde (tardive) ne le fait pas. Il y a des avantages et des inconvénients à la fois (ie la liaison anticipée est plus rapide, donne l'intellisense, le débogage plus facile, etc.) http://word.mvps.org/faqs/interdev/earlyvslatebinding.htm

Answer 2

@bugtussle Bien que vos instructions soient correctes, les instructions de wqw le sont aussi. Si vous utilisez le nouveau mot-clé ou CreateObject n'a rien à voir si un objet est lié tôt ou tard. Ce qui compte est de savoir si vous déclarez la variable objet avec un type enregistré ou non. Je crois que vous l'expliquez correctement dans votre article.

Je voudrais également mentionner que votre article est bien écrit et qu'il contient de bonnes informations, mais IMHO contient également quelques petites inexactitudes. Ce que vous appelez la liaison "Dual Interface" dans votre article (et vous l'expliquez bien) est généralement appelé "vTable" ou "très tôt". VB6 prend en charge la liaison vTable lorsque cela est possible. Maintenant, comme vous l'avez dit, la seule exigence pour être une classe COM est que la classe doit implémenter iUnknown. Une "interface double" signifie simplement une classe COM qui implémente à la fois iUnknown et iDispatch: une classe COM qui prend en charge la liaison tardive doit implémenter cette dernière. VB ne prend pas directement en charge les objets COM qui n'implémentent pas iDispatch (certaines classes COM ne prenant pas en charge la liaison tardive et d'autres qui posent problème dans VB); En d'autres termes, VB prend uniquement en charge les classes COM qui implémentent une interface double. (Cependant, il y a des astuces utilisant le message GETOLEINTERFACE de SendMessage qui contournent l'exigence.)

De même, il n'est pas tout à fait que iUnknown soit complètement ignoré, c'est que iUnknown.QueryInterface() est contourné, allant directement à la virtual table. iUnknown.AddRef() est toujours appelé, bien sûr. En ce qui concerne New vs. CreateObject: VB a une stratégie d'optimisation pour les classes définies dans un projet qui sont instanciées dans ce projet en utilisant le mot-clé New. Cependant, il existe également des différences importantes entre les deux si vous utilisez une classe en dehors du contexte d'un projet; cette page http://msdn.microsoft.com/en-us/library/Aa241758 fait un bon travail de les résumer.

Je suis également curieux de savoir quelle erreur l'OP a eu. :)