Board index » cppbuilder » Where to put the methods.

Where to put the methods.

hi,

I have a stand alone executable prg I have automated with a COM
Automation Server.  In the COM's code I have one method.  When this
method is called, I would like it in turn to go can call some methods in
my .exe.

To create the application I do:
File|New Application.
File|New|ActiveX|Automation Server

My quests are:
    1. How do I reference the methods in my executable file?
    2. Is it ok to keep the methods in the executable file, or should I
put them in the COM?
        - some use VCL components like TQuery.

Thanks,
    Jason

--
.............
......... Jason C. Leach
...... University College of the Cariboo
... j...@mail.ocis.net
.. http://www.ocis.net/~jcl
.

The Search for Extraterrestrial Intelligence from Home:
http://setiathome.ssl.berkeley.edu

 

Re:Where to put the methods.


Quote
Jason wrote:

> hi,

> I have a stand alone executable prg I have automated with a COM
> Automation Server.  In the COM's code I have one method.  When this
> method is called, I would like it in turn to go can call some methods in
> my .exe.

In which EXE? The client EXE that is automating you, or the EXE that is
the automation server?

If you want to callback into the client EXE, then the client will also
need to be an automation server. That doesn't sound like what you want,
but this is a useful scenario is some cases (its simpler than connection
points IMO).

It sounds like you want to know if the COM part of your server can call
methods of the non-COM parts of the server. The answer is yes. Here is a
quick example. I created an automation object that has a FooBar
interface with a DoSomething method. This function calls the DoSomething
method of the mainform.

//FooBarImpl.cpp
#include <vcl.h>
#pragma hdrstop

#include "FOOBARIMPL.H"
#include "unit1.h"      // include main form header

STDMETHODIMP TFooBarImpl::DoSomething()
{
    Form1->DoSomething();
    return S_OK;

Quote
}

By the way, this is exactly what a remote datamodule is. Its a COM
object that knows about an instance of a datamodule.

The reverse scenario, where the non-COM parts of the server call the COM
parts of the server, is not as easy. The reason is that the form does
not have an instance of IFooBar at its disposal. I suppose if you passed
it an IFooBar, then the main form of the server could do something with
it.

Harold Howe [TeamB]
http://www.bcbdev.com

Other Threads