How rreliable is the CLSID method of obtaining a file location?
in [Visual Basic]
|
Prev: problem emailing attachment with COD method
Next: Loading Excel via VB - Resize issue with over 255 characters in a
From: Paul Clement on 9 Jul 2010 08:58 On Thu, 08 Jul 2010 23:35:33 -0500, ralph <nt_consulting64(a)yahoo.net> wrote: � >� >Using the Registry would be a crapshoot at best, especially with MDAC and WDAC. As a matter of fact � >� >I don't believe that msado15.dll is associated with any CLSIDs. � >� > � >� � >� What a bizzare statement. But I guess it will depend on what you mean � >� by "associated"???? � > � >I chose not to elaborate. I did not find any CLSIDs that referenced msado15.dll directly. � � I gave you one. � [HKEY_CLASSES_ROOT\CLSID\{00000535-0000-0010-8000-00AA006D2EA4}\InprocServer32] � "C:\Program Files\Common Files\System\ado\msado15.dll" � � That CLSID references the ADODB.Recordset Interface. � Using that CLSID directly references the Registered component that � supports that interface - providing the filename and location. My search of the Registry didn't turn up anything because I messed up and had the "match full string" option selected. I stand corrected. Thanks for the info. :-) I haven't had to deal with an MDAC/ADO installation in a while, since it's been deployed with the OS for quite some time, but working with and identifying the version has always been problematic. Component Checker: Diagnose problems and reconfigure MDAC installations http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q307255& Paul ~~~~ Microsoft MVP (Visual Basic)
From: Mayayana on 9 Jul 2010 09:03 | No one apparently wants to learn COM/OLE. <g> | But it is absolutely necessary to move from an intermediate to | 'advanced' Windows programmer. | I'm often surprised by that lack of interest. For me, COM and Shell and two of the most interesting things because they're dealing so much with the functionality of the interface between a person and the Windows tool. But few people seem to share that interest. Maybe that's because many of the people here have a background in databases, record keeping software, MS Office automation, or other related specialties that are focused on business tasks. Or to put it another way, if they're making good money on their particular soup recipe there's no reason they should be interested in techniques for customizing their stove. :) | In spite of all the hype - COM ain't going away anytime soon. | | [Note: COM is the protocol. There is a COM 'Standard'. | OLE is the implementation. There is a de facto OLE 'Standard' called | OLE 2. Using OLE there are many ways to skin a "COM" cat.] | | > When it's COM there are 2 ways to load it. Early/vtable | >binding and late/dispatch binding. Most COM libraries | >are compiled with a dual interface -- you can use either | >method. Some libraries meant to be used by native code | >might only have early binding interfaces, but I don't know | >of any offhand. In rare cases there might be only | >dispatch binding. (Example: MSI.dll. WindowsInstaller.Installer | >offers only dispatch binding. It's an odd design. There's | >an API for C++ and a dispatch interface for script. But | >MS seems to have deliberately left VB out of their planning.) | > | > Early binding in VB is | >"as New...". It requires access to the typelib for the | >library, so that VB can resolve the function pointers at | >compile time and identify the data types. Your EXE can | >then load the library (which VB does transparently) and | >call the methods directly. | > | > "CreateObject..." is late binding. It's slow and used | >mainly by script. The data types are only variant or object. | >If the library has a dispatch interface, the vtable will have | >several standardized functions that a caller can use without | >knowing anything else about the library. Those functions | >allow for accessing the typelib and "discovering" the vtable | >offset of given methods. | > | | Early or Late Binding is determined by how the Interface is declared. | All 'Dim' references are called "Object References" because they used | to reference concrete objects, but are actually references to specific | Interfaces which must be assigned a concrete object before they can be | used. | With the statement: | Dim a As ALibrary | VB can resolve the reference with an included TypeLib at parse/compile | time. | You can intialize a reference to point to specific object using either | "New", CreateObject(), or GetObject(). New basically calls | CreateObject() in the background. | | With the statement: | Dim o As Object | You get late-binding. | | Note: without a typelib that defined "ALibrary" the statement: | Dim oA As ALibrary | would return an error as the interface name couldn't be resolved. In | which case you can still get an object using the ProgID/AppID | *string*. That's why Create/GetObject is needed to use IDispatch. | | "Dual" is actually a IDL attribute which allows an IUnknown and | IDispatch interface to be describe within the same library block. It | is useful as you noted because the same named Interfaces can be | accessed using the same GUIDs, and is the default Interface produced | by VB when it creates ActiveX components. VB/VBA 5/6 can access | IUnknown, IDispatch, or Dual interfaces. Scripting languages are | limited to using IDispatch/Dual simply because they can't use TypeLibs | or include 'header' files. | | There is absolutely no way to adequately address COM and OLE within | this media. Poor Tony has to get a few good books and take the time to | learn it. <g> | | -ralph
From: Paul Clement on 9 Jul 2010 09:07 On Thu, 08 Jul 2010 14:58:01 -0700, Karl E. Peterson <karl(a)exmvps.org> wrote: � >> . I did not find any CLSIDs that referenced msado15.dll directly. � > � > That's puzzling because ADO is part of WIndows OS since 2000. � > � >> My � >> understanding is that the interfaces are registered through the ADO version � >> specific type libraries. � > � > When you look at the ADO references there are multiple references � > available as I'm sure you've noticed. All but the most recent � > reference are TLBs. The most recent is to the msado15.dll. � � You gotta remember, Paul's just here as an Agent of FUD. Believe it or not, I'm a double-agent working for KAOS. Paul ~~~~ Microsoft MVP (Visual Basic)
From: Paul Clement on 9 Jul 2010 09:24 On Thu, 08 Jul 2010 15:26:12 -0600, Tony Toews <ttoews(a)telusplanet.net> wrote: � >My � >understanding is that the interfaces are registered through the ADO version specific type libraries. � � When you look at the ADO references there are multiple references � available as I'm sure you've noticed. All but the most recent � reference are TLBs. The most recent is to the msado15.dll. Yeah, bad searching on my part. The following key might help as well (if you're not concerned about potential mismatched MDAC files): HKEY_LOCAL_MACHINE\Software\Microsoft\DataAccess (FullInstallVer key) Otherwise, the Component Checker tool is the most reliable method. http://www.microsoft.com/downloads/details.aspx?FamilyId=8F0A8DF6-4A21-4B43-BF53-14332EF092C9&displaylang=en Paul ~~~~ Microsoft MVP (Visual Basic)
From: Paul Clement on 9 Jul 2010 09:30
On Thu, 8 Jul 2010 13:16:31 -1000, "Randem" <newsgroups(a)randem.com> wrote: � Ok, I guess the underlying question is why does one need to know which of � these version are installed. I remember MS had a tool to attempt to verify � this same thing and the tool came up with different versions installed due � to mis-matched version being installed. Good point since Vista and Windows 7 would be off limits with respect to an install (with exception to the ACE OLEDB Provider). � I would think that you would just install the version you need and be done � with it. What am I missing here? See above. Paul ~~~~ Microsoft MVP (Visual Basic) |