From: ralph on
On Thu, 8 Jul 2010 10:02:30 -0400, "Mayayana"
<mayayana(a)invalid.nospam> wrote:

Minor nitpicks and comments.

>|
>
> Since VB types align with COM types, and VB is designed
>to easily access COM objects, most of the mechanics of
>it is hidden.

The primary reason "COM" seems such a mystery to VBers, and confusing
to C/C++ programmers. <g>

> In C++ COM manifests as interfaces and
>is apparently more cumbersome. At one point I came
>across a posting by Raymond Chen where he used
>a bizarre amount of Shell COM code. If I remember correctly
>he was demonstrating that it was possible to access a
>ShellFolderView object. (The object that wraps a folder
>window listview.) For some reason he demonstrated a
>circuitous method. In any case, the post was followed by
>grumpy comments from C++ people lamenting that they
>had to deal with COM.
>

No one apparently wants to learn COM/OLE. <g>
But it is absolutely necessary to move from an intermediate to
'advanced' Windows programmer.

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: ralph on
On Thu, 08 Jul 2010 12:07:41 -0500, ralph <nt_consulting64(a)yahoo.net>
wrote:

Should have included ...

>
>With the statement:
> Dim o As Object
or
Dim o As Variant
>You get late-binding.
>

From: ralph on
On Thu, 08 Jul 2010 11:06:38 -0500, Paul Clement
<UseAdddressAtEndofMessage(a)swspectrum.com> 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"????

CLSIDs are given to available "Interfaces". All Interfaces are
associated with a respective registered component. eg.

[HKEY_CLASSES_ROOT\CLSID\{00000535-0000-0010-8000-00AA006D2EA4}\InprocServer32]
"C:\Program Files\Common Files\System\ado\msado15.dll"

A programmer can retrieve the location and name of the component the
same way the COM library does - by de-referencing the "associated"
component from the CLSID for the Interface.

>Probably best to check the known locations of the DLLs based upon the OS version and get then grab
>the file version information.

The only problem with this - ActiveX components are not actually
limited to a few *KNOWN* locations, but rather the logical/physical
location they are registered from. Logical/physical locations can
vary. The CLSID never does.

It is possible to actually have more than one file version/copy on a
box, but only the one that is registered for a particular VM is
"useable".

Using the CLSID and thus uncovering the specific location a registered
component is located at seems to be more reliable.

-ralph
From: Paul Clement on
On Thu, 08 Jul 2010 14:22:45 -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. My
understanding is that the interfaces are registered through the ADO version specific type libraries.


Paul
~~~~
Microsoft MVP (Visual Basic)
From: Tony Toews on
On Thu, 08 Jul 2010 14:53:13 -0500, Paul Clement
<UseAdddressAtEndofMessage(a)swspectrum.com> 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.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/