Re: Replacements for IsValidIID and IsValidInterface

From: Brian Muth (bmuth_at_mvps.org)
Date: 01/11/05 

Date: Mon, 10 Jan 2005 20:20:19 -0800

"David Liebtag" <DavidLiebtag@vermontel.net> wrote in message
news:1105412858.907084@vader.vermontel.net...
> My code is not a server; it's an interface that lets an APL2 application
> operate as a client (if I understand the terms server and client as they
are
> used in COM-world; I'm new to this stuff.).

The terminology is very important to have straight here, otherwise both you
and I will become confused what each other means. Permit me to clarify.

An interface is implemented by a COM object and is referred to as the
server. A client calls into the COM server's interface in order to access a
property or invoke a method. But it is the COM server that executes as a
result of the call.

The client can acquire a pointer to a particular interface by a variety of
means, such as calling CoCreateInstance() or by calling QueryInterface()
using a previously acquired different interface pointer. Regardless of how
it is acquired, it is the client's responsibility for calling the Release()
method on the interface to let the COM server know that the client is
finished with that particular interface pointer. This is very important and
lies at the core of COM.

In your scenario you refer to "the App calling the APL2-COM interface". In
this case, App is the client, and the code implementing the APL2-COM
interface is the server (whether it resides in the App or not). In your
post, the App is passing an integer representing an IDispatch pointer and
you expect the APL2-COM interface (ie the server) to call IDispatch::Invoke.
App is the client and is the owner of the IDispatch interface. By COM rules,
App is responsible for calling Release() on this IDispatch interface.....
however, in your design I don't see where this is being done. If you expect
the APL2-COM interface to call Release() on behalf of App, you have a design
issue which needs to be addressed if you are going to avoid a memory leak.

Please don't take my questions as a criticism.... I'm simply trying to guide
your thinking to recognize some potential problems.

Brian

  And, it knows when APL2 goes
> down because it is part of APL2.
>
> David Liebtag
>
>
>

Relevant Pages

  • Re: What doesnt lend itself to OO?
    ... >> proxy and instructs the server to constuct the real object. ... rather than client code. ... If 'clock' is instantiated in the server, ... > for the server interface at the OOA level. ...
    (comp.object)
  • Re: What doesnt lend itself to OO?
    ... >> The problem with stateless programming is that it turns object ... > server is a pure data transfer interface. ... So the client should be ...
    (comp.object)
  • Re: What doesnt lend itself to OO?
    ... > A pure data transfer interface consists of messages that have a message ... > essentially exposing the client or service implementation. ... stateless ones like web services etc look like ... I was using the IT view of client/server where the server ...
    (comp.object)
  • Re: Windows Service in VB
    ... Your service needs to expose an interface via .Net remoting. ... and register the public class as a well-known singleton. ... You also need to create a WinForms app that can be run by logged-in users. ... if your client app just wants to call methods on the service's remoted ...
    (microsoft.public.dotnet.languages.vb)
  • Re: What doesnt lend itself to OO?
    ... The whole idea that a subsystem is just ... > The first line exists in the server. ... objects between client and server i.e. as far as the client code is ... > external interface is the traditional input interface whose ...
    (comp.object)