tags:

views:

43

answers:

2

I'm writing a simple vb6 button which tests the access of the registry values.

I have the following:

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

I have Project Menu -> References and select Microsoft WMI Scripting V1.1 Library selected and Windows Script Host Object Model referenced

however my msgbox is still coming up blank. I did check the registry path and it is correct. any ideas?

thanks in advance.

+1  A: 

You need to comment out the line 'on error resume next' while you are developing. If an error is occurring, you will not be able to see the details. It could be not found or access denied etc.

Also there are two ways to reference an object. Early binding ie Dim rs as new adobdb.recordset and late binding set rs = CreateObject("Adodb.recordset"). The first method (early binding) forces you to declare a reference and the second (late) does not. There are advantages and disadvantages to both (ie early binding is faster, gives intellisense, easier debugging, etc) http://word.mvps.org/faqs/interdev/earlyvslatebinding.htm

bugtussle
yea i just caught that.. i get the error at registry.regread method
phill
what is the error?
bugtussle
`Dim rs As ADODB.Recordset : Set rs = CreateObject("ADODB.Recordset")` is early-binding. `Dim rs As Object : Set rs = new Recordset` is late-bound.
wqw
You are incorrect. `dim rs as adodb.recordset` is early binding. You do not need to `createobject` when early binding. please see http://kandkconsulting.tripod.com/VB/Tutorials/vb_binding_tutorial.htm
bugtussle
A: 

@bugtussle While your statements are correct, wqw's statements are also. Whether you use the New keyword or CreateObject actually hasn't anything to do with whether an object is early or late bound. What does matter is whether you declare the object variable with a registered type or not. I believe that you actually explain this correctly in your article.

I'd like to mention also that your article is well-written and has good information, but IMHO contains also a couple of minor inaccuracies. What you call "Dual Interface" binding in your article (and explain well) is generally referred to as "vTable" or "very early" binding. VB6 supports vTable binding where possible.

Now, as you have said, the sole requirement to be a COM class is that the class must implement iUnknown. A "dual interface" simply means a COM class that implements both iUnknown and iDispatch: a COM class that supports late binding must implement the latter. VB doesn't directly support COM objects that don't implement iDispatch (having some COM classes that don't support late binding and some that do would pretty clearly be problematical in VB); in other words VB only supports COM classes that implement a dual interface. (However, there are tricks using SendMessage's GETOLEINTERFACE message that bypass the requirement.)

Also, it isn't quite that iUnknown is bypassed altogether, it is that iUnknown.QueryInterface() is bypassed, instead going directly to the virtual table. iUnknown.AddRef() is still called, of course.

Regarding New vs. CreateObject: VB has an optimization strategy for classes defined within a project that are instantiated within that project using the New keyword. However, there are also important differences between the two if you are using a class outside of a project context; this page http://msdn.microsoft.com/en-us/library/Aa241758 does a good job of summarizing them.

I'm curious as well to know what error the OP got. :)

BobRodes