Dispatch Interface - mixing properties and methods.

[Mark Alexander Bertenshaw]

Hi -

I have been recently updating a type library that was distributed with an
ancient MFC automation DLL we have been maintaining. In order to ensure
that we can see what properties and methods are allowed by the DLL, I
decided to dust down the (unused) type library, and replace all the As
Object references with the single exposed coclass in the type library, which
has a default dispatch interface. When I did this, all projects
referencing the type library worked fine.

However, looking at the type library, I noticed that none of the properties
that I knew that the DLL exposed were actually in the type library, so I
added them. And now (in a really contrary way) the compiler complains that
none of the properties exist! Looking at 3rd party Dispatch interfaces, I
noticed that they never mixed properties and methods. Could there be some
logic behind this? Does anyone know how I can add the properties without
this problem?

Thanks,

--
Mark Alexander Bertenshaw
Programmer/Analyst
Chordiant Software, Inc.
Brentford
UK

[Mark Alexander Bertenshaw]

Correction: The problem does not happen at compile-time: it is at run-time.
The property gives "Object does not support this property or method."

--
Mark Alexander Bertenshaw
Programmer/Analyst
Chordiant Software, Inc.
Brentford
UK
"Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote in message
news:3d231531@10.1.10.29...
> Hi -
>
> I have been recently updating a type library that was distributed with an
> ancient MFC automation DLL we have been maintaining. In order to ensure
> that we can see what properties and methods are allowed by the DLL, I
> decided to dust down the (unused) type library, and replace all the As
> Object references with the single exposed coclass in the type library,
which
> has a default dispatch interface. When I did this, all projects
> referencing the type library worked fine.
>
> However, looking at the type library, I noticed that none of the
properties
> that I knew that the DLL exposed were actually in the type library, so I
> added them. And now (in a really contrary way) the compiler complains
that
> none of the properties exist! Looking at 3rd party Dispatch interfaces, I
> noticed that they never mixed properties and methods. Could there be some
> logic behind this? Does anyone know how I can add the properties without
> this problem?
>
> Thanks,
>
> --
> Mark Alexander Bertenshaw
> Programmer/Analyst
> Chordiant Software, Inc.
> Brentford
> UK
>
>

[Eduardo A. Morcillo [MVP]]

Mark Alexander Bertenshaw wrote:
> Correction: The problem does not happen at compile-time: it is at run-
> time. The property gives "Object does not support this property or
> method."

When you add methods and properties to the type library for a dispinterface
VB will get the DISPIDs from the type library at compile-time instead of
calling IDispatch.GetIDsOfNames to get the DISPIDs from the method name at
run-time. If you have set the wrong DISPIDs in the type library the call to
IDispatch.Invoke will fail with the "Object does not support this property
or method." error.

--
Eduardo A. Morcillo [MS MVP-VB]
http://www.domaindlx.com/e_morcillo

[Mark Alexander Bertenshaw]

Eduardo -

Thanks for the reply. I did find out what the problem was in the end by
trial and error. It seems that MFC ActiveX DLLs do not explicitly map a
particular ID to a particular function. It seems that it assigns IDs from 1
upwards, for each method declation after the DECLARE_OLECREATE() macro. How
Visual C++ does it - I've no idea. Guessing that each pair of properties
counted as a single member of the type library, I was able to work out all
the member IDs.

Incidentally, I suspect that you are only nearly right. It seems that when
you use a type library with a dispatch interface, the member IDs get
compiled into the EXE - otherwise, I would have to distribute the type
library with the EXE. The "object does not support this property or method'
error was occurring because the memberID did not exist. This means that the
client code is only calling Invoke().

--
Mark Alexander Bertenshaw
Programmer/Analyst
Chordiant Software, Inc.
Brentford
UK

"Eduardo A. Morcillo [MVP]" <emorcilloATmvps.org> wrote in message
news:3d27d779@10.1.10.29...
> Mark Alexander Bertenshaw wrote:
> > Correction: The problem does not happen at compile-time: it is at run-
> > time. The property gives "Object does not support this property or
> > method."
>
> When you add methods and properties to the type library for a
dispinterface
> VB will get the DISPIDs from the type library at compile-time instead of
> calling IDispatch.GetIDsOfNames to get the DISPIDs from the method name at
> run-time. If you have set the wrong DISPIDs in the type library the call
to
> IDispatch.Invoke will fail with the "Object does not support this property
> or method." error.
>
> --
> Eduardo A. Morcillo [MS MVP-VB]
> http://www.domaindlx.com/e_morcillo
>
>

[James Barbetti]

Hi Mark.

>Thanks for the reply. I did find out what the problem was in the end by
>trial and error. It seems that MFC ActiveX DLLs do not explicitly map
a
>particular ID to a particular function. It seems that it assigns
>IDs from 1 upwards, for each method declation after the
>DECLARE_OLECREATE() macro. How Visual C++ does it - I've no idea.

It's more that sometimes - so far as I can tell - it doesn't do it at all.
See below.

>Guessing that each pair of properties counted as a single member of
>the type library, I was able to work out all
>the member IDs.

Re: "object does not support this property or method" messages.

When I am building a C++ library to be incorporated into a VB project and
I have added or removed - or even changed - properties or methods, I routinely
delete the ".exp" and ".lib" files in the release folder before I do the
rebuild. Otherwise I - sometimes - see the "object does not support this
property or method" messages at runtime. Strangely the properties and methods
are listed fine at development time (weird!). My guess is that the C++ compiler
(version 6, anyway) is not always rebuilding all the information it *ought*
to. Deleting the ".lib" and ".exp" files before a rebuild seems to "wake
it up". Usually I knock out the ".dll" file too.

>Incidentally, I suspect that you are only nearly right. It seems
>that when you use a type library with a dispatch interface, the
>member IDs get compiled into the EXE - otherwise, I would have
>to distribute the type library with the EXE.

Pretty much. They *have* to go into the EXE, because of the way the IDispatch
interface (==what VB calls an "Object") is implemented. Though I suppose
you could, if you wanted to, build versions of IDispatch that supported ::Invoke
but stubbed ::GetTypeInfo and ::GetTypeInfoCount.

>The "object does not support this property or method'
>error was occurring because the memberID did not exist. This
>means that the client code is only calling Invoke().

Yes. Based on the member ID's it pulls from the type library information
(which doesn't always seem to be updated correctly by the C++ compiler; it
can get out of synch with the member ID's actually supported by the IDispatch::Invoke()
overrides for the compiled classes in the DLL).

Hope this helps,
James

[Mark Alexander Bertenshaw]

"James Barbetti" <james_barbetti@yahoo.com> wrote in message
news:3d2a287c$1@10.1.10.29...

James -

>
> Hi Mark.
> >It seems that MFC ActiveX DLLs do not explicitly map a
> >particular ID to a particular function. It seems that it assigns
> >IDs from 1 upwards, for each method declation after the
> >DECLARE_OLECREATE() macro. How Visual C++ does it - I've no idea.
>
> It's more that sometimes - so far as I can tell - it doesn't do it at all.
> See below.

Presumably this ID allocation is being done at precompile time. I can't say
that I am very familiar with the magic of the C/C++ precompiler, so it's all
foreign to me.

> >Guessing that each pair of properties counted as a single member of
> >the type library, I was able to work out all
> >the member IDs.
>
> Re: "object does not support this property or method" messages.
>
> When I am building a C++ library to be incorporated into a VB project and
> I have added or removed - or even changed - properties or methods, I
routinely
> delete the ".exp" and ".lib" files in the release folder before I do the
> rebuild. Otherwise I - sometimes - see the "object does not support this
> property or method" messages at runtime. Strangely the properties and
methods
> are listed fine at development time (weird!). My guess is that the C++
compiler
> (version 6, anyway) is not always rebuilding all the information it
*ought*
> to. Deleting the ".lib" and ".exp" files before a rebuild seems to "wake
> it up". Usually I knock out the ".dll" file too.

I suppose it is a failure in the make file (or whatever VC uses internally).
Could it be a read-only attribute or something?
I have worked out that ".lib" files contain a list of all the external DLL
functions, and their offsets, but I have no idea what the ".exp" is supposed
to do.

> >Incidentally, I suspect that you are only nearly right. It seems
> >that when you use a type library with a dispatch interface, the
> >member IDs get compiled into the EXE - otherwise, I would have
> >to distribute the type library with the EXE.
>
> Pretty much. They *have* to go into the EXE, because of the way the
IDispatch
> interface (==what VB calls an "Object") is implemented. Though I suppose
> you could, if you wanted to, build versions of IDispatch that supported
::Invoke
> but stubbed ::GetTypeInfo and ::GetTypeInfoCount.

Would there be any point?

> >The "object does not support this property or method'
> >error was occurring because the memberID did not exist. This
> >means that the client code is only calling Invoke().
>
> Yes. Based on the member ID's it pulls from the type library information
> (which doesn't always seem to be updated correctly by the C++ compiler; it
> can get out of synch with the member ID's actually supported by the
IDispatch::Invoke()
> overrides for the compiled classes in the DLL).

Interesting. I'll have to bear that in mind.

Subsiduary question: Do you know how easy it would be to replace the
IDispatch interface with a IUnknown based interface? The crazy thiing is
that this component is the sole route through which communication via the
RPC layer is done. There are rudimentary recordset features in the code,
and so potentially each method could be called hundreds of times. This late
binding seems very silly. I suspect that the (now departed) resident genius
who wrote this code hadn't researched COM or Automation. Take it this way,
there are too many comments in the code saying // TODO: Add your dispatch
handler code here.

>
> Hope this helps,
> James

Thanks,

--
Mark Alexander Bertenshaw
Programmer/Analyst
Chordiant Software, Inc.
Brentford
UK