Board index » cppbuilder » Implementing tlb Source Interface methods for client

Implementing tlb Source Interface methods for client

    I have a type library from a COM server which includes an ICallback
interface identified as Source.  I want to write the client
implementation for the methods in this Source interface so that I can
create an instance and pass it to the server.  Is there a wizard or
other approach that automatically generates the skeleton code for the
client such as the ...impl.cpp file generated when writing the COM
server?

thanks,

Curtis.

 

Re:Implementing tlb Source Interface methods for client


Curtis, you can create a CoClass and copy/paste the ICallback interface
to it. Mark the CoClass hidden ( so it doesn't show up in the object map
). This should generate code for the ICallback.

Alex

Quote
Curtis Brown wrote:

[snip]

Re:Implementing tlb Source Interface methods for client


Actually, there's no need to even mark the thing hidden ...
Quote
"Alex Bakaev [TeamB]" wrote:

> Curtis, you can create a CoClass and copy/paste the ICallback interface
> to it. Mark the CoClass hidden ( so it doesn't show up in the object map
> ). This should generate code for the ICallback.

> Alex

> Curtis Brown wrote:
> [snip]

Re:Implementing tlb Source Interface methods for client


    Could you provide a few more of the steps?  Am I suppose to import
the type library into my client projects; add a COM object placeholder
to the client; -- where am I adding the CoClass?

thanks,

Curtis.

Quote
Alex Bakaev [TeamB] wrote:
> Curtis, you can create a CoClass and copy/paste the ICallback
> interface
> to it. Mark the CoClass hidden ( so it doesn't show up in the object
> map
> ). This should generate code for the ICallback.

> Alex

> Curtis Brown wrote:
> [snip]

Re:Implementing tlb Source Interface methods for client


Quote
Alex Bakaev [TeamB] wrote:
>Curtis, you can create a CoClass and copy/paste the ICallback interface

to it. Mark the CoClass hidden ( so it >doesn't show up in the object
map). This should generate code for the ICallback.

Let me verify if I have the steps correct...

- Create a Client as a standard application
- Import the Type Library so I can create instances of the server
- Add a ComObject to my Client
- Open the Server's Type Library in a separate window and copy its
ICallback Interface into my client's Type Library
- Refresh the client to generate an ..impl.cpp for the ICallback
functions which I then fill in a desired
- As needed, create an instance of the Server Object (possibly remote)
- Create an instance of the client's COM object and pass a pointer to it
to the Server's Advise method.

    Is it because both interfaces are using the same GUID that the
Server will accept the Client's ICallback as the type it was expecting
even though it is defined under a different CoClass?  Have I complicated
the process more than you intended?  I hope not to have to use a second
COM object locally.

thanks,

Curtis.

Re:Implementing tlb Source Interface methods for client


Curtis, the steps seem correct. As for if this will work or not -
experiment ;). I'm not sure what you mean by the same GUID, etc.
Basically, you want to sink events from the server. This is handled by
importing the server's type library and using TEventsDispatcher class. I
think samples of this were posted here.

Alex

Quote
Curtis Brown wrote:

[snip]

Re:Implementing tlb Source Interface methods for client


Quote
Alex Bakaev [TeamB] wrote:
> Basically, you want to sink events from the server. This is handled by

> importing the server's type library and using TEventsDispatcher class.
> I
> think samples of this were posted here.

   Could I step back and make sure we are on the same wavelength?  I
have seen some of the threads about TEventsDispatcher in conjunction
with event support / connection points.  Does it apply equally to custom
callback interfaces, which is what I am trying to implement in this
case.  IOW, my client defines the interface implementation, creates an
instance and passes it to the server in an Advise.  The server then
calls the methods as appropriate.

    For example, the server contains following code...

ICallback *gpCallback;

MyServ::Advise
STDMETHODIMP TMyServ::Advise(ICallback *pCallBack)
{
  gpCallback = pCallBack;
  return S_OK;

Quote
}

later, the server simple calls

    if ( gpCallback )
        gpCallback->StatusUpdate( lStatus );

    I'm actually taking my example from the book, "Active Template
Library", which is based on VC++ and VB.  This is where I was led to
define the ICallback interface in the server's type library tagged as
Source.  The chapter then goes on to show how to create the
implementation of the interface under VB and it looks (and is -- I tried
it) real easy.  I actually do have a team member that will do a VB
implementation so that's all well and good.  Of course, I need to figure
out as well how to generate the implemenation in BCB.

just checking,

Curtis.

Re:Implementing tlb Source Interface methods for client


Curtis, Advise(), et al are part of the connection points and used for
event sinking. I.E. a server is calling a client. I wonder why you can't
create an events interface in the TLE and use that ( which is basically
is your ICallback ).

Alex

Quote
Curtis Brown wrote:

[snip]

Re:Implementing tlb Source Interface methods for client


Quote
Alex Bakaev [TeamB] wrote:
> Curtis, Advise(), et al are part of the connection points and used for

> event sinking. I.E. a server is calling a client. I wonder why you
> can't

    I wrote the Advise method as a custom method to accept my callback
interface.

Quote
> create an events interface in the TLE and use that ( which is
> basically
> is your ICallback ).

   The primary motivation of using a custom callback is that I have
several status events that I must allow each client to specify their
desired frequency of notification.  As I understand the standard
connection point interface, I call a Fire... method and the prefab code
triggers its corresponding callback for all clients.  I need more
controlled behavior -- thus the _custom_ callback approach.

Curtis.

Re:Implementing tlb Source Interface methods for client


Curtis, you can always modify the prefab Fire_xxx code :) You can even
QI the particular client in the Fire_xxx for an interface and ask if the
client is interested in getting an event, etc.

a.

Quote
Curtis Brown wrote:

> Alex Bakaev [TeamB] wrote:

> > Curtis, Advise(), et al are part of the connection points and used for

> > event sinking. I.E. a server is calling a client. I wonder why you
> > can't

>     I wrote the Advise method as a custom method to accept my callback
> interface.

> > create an events interface in the TLE and use that ( which is
> > basically
> > is your ICallback ).

>    The primary motivation of using a custom callback is that I have
> several status events that I must allow each client to specify their
> desired frequency of notification.  As I understand the standard
> connection point interface, I call a Fire... method and the prefab code
> triggers its corresponding callback for all clients.  I need more
> controlled behavior -- thus the _custom_ callback approach.

> Curtis.

--
HotSend - portable documents technology
http://www.hotsend.com/
eFax - get your faxes via email - Free !
http://www.efax.com

Other Threads