Having only one instance an OLE Automation server
Jean-Louis Herman
I have the following problem: I created a VC++ OLE Automation server
that exposes a certain foo class. I would like that each time an OLE
Automation client creates a foo object, that this object be instantiated
in the SAME instance of the OLE Automation server.
In practice, I would like to start an application (my OLE Automation
server) and that each time a client creates a foo object, the object is
"provided" by this running instance of the server. This would allow the
running server to (for example) keep a list of all foo objects and would
allow some "interprocess" communication between all OLE clients with the
server being the central point.
Help much appreciated,
Thanks,
Jean-Louis Herman
Logica SA Brussels
(Standard disclaimer)
Tom Armstrong
Jean-Louis Herman <her...@logica.com> wrote:
What you're describing isn't difficult as long as the automation server is
implemented as a local server. Is this the case? If it is then flag the server
as multi-use and all clients will use the same instance of the server. If, on the
other hand, your server is in-process, then you've got a much more difficult problem.
In-process servers are DLLs and operate in the clients address space (Win32) so
you will always get another instance of the server.
If you're using MFC, the multiuse flag is set during the m_server.ConnectTemplate
call. The default is for MDI apps to be multi-instance and for SDI apps to be
single-instance. The terms single and multi-instance are confusing, but they
described the behavior from the server's perspective. So in your case you
want a mult-instance server.
TwA
(OCX FAQ)
http://www.sky.net/~toma
Brian Ebarb
>
> If you're using MFC, the multiuse flag is set during the m_server.ConnectTemplate
> call. The default is for MDI apps to be multi-instance and for SDI apps to be
> single-instance.
OK, but what if his server isn't document-based, and therefore he
doesn't personally call ConnectTemplate? I'm looking into this one
myself, and haven't yet come to the definitive answer. Sounds like
a darned interesting discussion topic tho.
--
- Brian Ebarb
Tom Armstrong
Brian Ebarb <eb...@airmail.net> wrote:
If your class isn't document-based, which I imagine is the typical case, the COleObjectFactory
class handles the multi-instance stuff. The default behavior is to create the class so
that it allows multiple instances of the object within the housing (EXE). If you don't want
this behavior, you must create a new IMPLEMENT_OLECREATE macro, with a different
name of course, and set the third parameter to the COleObjectFactory constructor
to TRUE instead of FALSE.
For additional details check out the above macro definition and the members of
COleObjectFactory, particularly the constructor.
TwA
(OCX/Automation FAQ)
http://www.sky.net/~toma/faq.htm
Randy Jensen
>
> OK, but what if his server isn't document-based, and therefore he
> doesn't personally call ConnectTemplate? I'm looking into this one
> myself, and haven't yet come to the definitive answer. Sounds like
> a darned interesting discussion topic tho.
All of this, of course, depends on how you multi-instanced you want your server to be.
.Do you want all clients to connect to the same instance of the server?
.Do you want all clients to connect to the same server object within the above instance?
.Are you working within a document architecture?
Anyhow, in order to have the best control over the non standard cases, you need to ditch the
IMPLEMENT_OLECREATE macro all together and just instantiate a COleObjectFactory derived class.
Within the derived class, override OnCreateObject. Once created and registred you now can do
whatever you wish -- any of the above type things or something else entirely.
The other interesting portion of this is do you want multiple servers running? What if the server
application is started a second time. Should it defer to the first? Should it not care. All of
this makes use of the RunningObjectTable and other neatly related types of contention control.
Brian Ebarb
>
> All of this, of course, depends on how you multi-instanced you want your server to be.
>
> .Do you want all clients to connect to the same instance of the server?
> .Do you want all clients to connect to the same server object within the above instance?
> .Are you working within a document architecture?
>
> Anyhow, in order to have the best control over the non standard cases, you need to ditch the
> IMPLEMENT_OLECREATE macro all together and just instantiate a COleObjectFactory derived class.
> Within the derived class, override OnCreateObject. Once created and registred you now can do
> whatever you wish -- any of the above type things or something else entirely.
>
> The other interesting portion of this is do you want multiple servers running? What if the server
> application is started a second time. Should it defer to the first? Should it not care. All of
> this makes use of the RunningObjectTable and other neatly related types of contention control.
I haven't ditched the IMPLEMENT_OLECREATE macro in the server I'm working on
now, but I'm thinking about it.
In this age of moving-target technologies, it's hard to maintain my personal
stack frame ("OK, which one of you classes is the new guy?"). I've got Inside
OLE 2nd Ed (Brockschmidt), OLE Automation Programmer's Reference (MS), and OLE
Programming in 21 Days (Harris) - and have been thinking about dumping the
App Wizard-generated stuff in favor of hand-coding. I've also been thinking about
dumping CDaoRecordset and recoding the database stuff using dbDAO, but that's
another topic!
What would I gain by hand-coding as opposed to trying to get by with App Wizard
generated code in my out-of-process no-user-interface automation server? Beats me.
I would like to hear from folks who have swung this rope both ways.
--
- Brian Ebarb
Jim Ricker
I only caught the tail end of this topic. But I think I have the same
problem. That is, How do I create an object server that only spawns
one out-of-process server process that can service multiple clients
when my objects are not documents?
Have you come up with any answers to your original question?
Jim Ricker
Brian Ebarb
Well, first, I'm using an out-proc EXE server instead of a DLL. I'm not
doing anything particularly special with it - and it doesn't APPEAR that
I'm getting multiple objects instantiated with it, even though the caller
(also a DLL) is being called by multiple apps, and would therefore be
a potential multi-instance hazard.
The following code was suggested by someone:
#define IMPLEMENT_OLECREATE_MULTI_INSTANCE(class_name, external_name, l, w1, w2,
b1, b2, b3, b4, b5, b6, b7, b8) \
AFX_DATADEF COleObjectFactory class_name::factory(class_name::guid, \
RUNTIME_CLASS(class_name), TRUE, _T(external_name)); \
const AFX_DATADEF GUID class_name::guid = \
{ l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } }; \
This would replace the IMPLEMENT_OLECREATE macro to force a multi-instance
capable app (which semantically is hazy as all getout). I think that a
multiple-instance capable server means that the exposed objects are reentrant.
--
- Brian Ebarb
Jim Sievert
>
> Mr. Ebarb,
>
> I only caught the tail end of this topic. But I think I have the same
> problem. That is, How do I create an object server that only spawns
> one out-of-process server process that can service multiple clients
> when my objects are not documents?
>
> Have you come up with any answers to your original question?
>
> Jim Ricker
The creation of new servers is controlled through the third parameter to the
COleObjectFactory constructor. This is the bMultiInstance parameter. It
"indicates whether a single instance of the application can support multiple
instantiations. If TRUE, multiple instances of the application are launched for
each request to create an object."
This behavior can also be controlled through the CoRegisterClassObject() function
which is encapsulated in the COleObjectFactory::Register() function.
In general, for MDI programs, this parameter is set to FALSE, indicating that a
single instance of the server will service all clients. For SDI programs, this
parameter is set to TRUE, indicating that an instance of the server will be
created for each client.
You have OLE objects that are not documents. This is fine. The basic OLE
functionality is encapsulated in CCmdTarget. Use Class Wizard to add a new
CCmdTarget derivative to your application. You can enable automation if you
wish. This new class will have the bMultiInstance parameter set to FALSE. This
will be done in the IMPLEMENT_OLECREATE macro...