Dispatch Interface - mixing properties and methods.


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 6 of 6

Thread: Dispatch Interface - mixing properties and methods.

  1. #1
    Mark Alexander Bertenshaw Guest

    Dispatch Interface - mixing properties and methods.

    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



  2. #2
    Mark Alexander Bertenshaw Guest

    Re: Dispatch Interface - mixing properties and methods.

    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
    >
    >




  3. #3
    Eduardo A. Morcillo [MVP] Guest

    Re: Dispatch Interface - mixing properties and methods.

    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



  4. #4
    Mark Alexander Bertenshaw Guest

    Re: Dispatch Interface - mixing properties and methods.

    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
    >
    >




  5. #5
    James Barbetti Guest

    Re: Dispatch Interface - mixing properties and methods.


    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

  6. #6
    Mark Alexander Bertenshaw Guest

    Re: Dispatch Interface - mixing properties and methods.

    "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



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center