CLSCTX_LOCAL_SERVER
Pascal Suter
I've just started writing com components with visual studio 6.0. My
first test was an inproc server using the atl/com wizard. I could
access my Interface_Methods via a client. This sample was successful.
As a second test, I tried to build a local server using again the
wizard and choosing executable in the dialog box. I added an Interface
IRemote (custom) with an interface method play(). My client called
CoGetClassObject(clsid, CLSCTX_LOCAL_SERVER, NULL, IID_IClassFactory,
(void **) &pClf) that returned me a pointer to my classfactory. Now I
could instantiate my object with calling pClf->CreateInstance
(NULL,IID_IUnknown,(void**) &pUnk). So I got access to the standard
interface IID_IUnknown. The next call to catch my Interface IRemote via
hres=pUnk->QueryInterface(IID_IRemote, (void**) &pRemote) failed. hres
returned E_NOINTERFACE.
I wonder what's wrong here. Why could I not access my interface,
although my interface does exist and my server is registred? I have no
idear.
Please help me to solve this problem. Here's the code of the client
that tries to access the server:
if(AfxOleInit()==0){
TRACE("Ole Initialization failed!");
};
class CRemote* pRemote = NULL;
CLSID clsid;
LPCLASSFACTORY pClf;
LPUNKNOWN pUnk;
HRESULT hr;
if ((hr = ::CLSIDFromProgID(L"DComServer.Remote",&clsid)) != 0){
TRACE("unable to find Program ID error = %x\n", hr);
return;
}
if ((hr = ::CoGetClassObject(clsid, CLSCTX_LOCAL_SERVER,
NULL, IID_IClassFactory, (void **) &pClf))!= 0) {
TRACE("unable to find CLSID ID error = %x\n", hr);
return;
};
pClf->CreateInstance(NULL,IID_IUnknown,(void**) &pUnk);
HRESULT result=pUnk->QueryInterface(IID_IRemote, (void**)
&pRemote);
int number=8;
pRemote->IPlay(number);//error, could not access method
pClf->Release();
pUnk->Release();
};
Yours sincerely, Pascal Suter
--
Pascal Suter Dipl. El.-Ing. ETH
Research Assistant Phone: ++41 (0)1 632 51 42
Gloriastrasse 35 Fax: ++41 (0)1 632 12 10
CH - 8092 Zürich E-Mail: su...@ife.ee.ethz.ch
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Peter Partch
implied for dual interfaces), then you need to register the typelib. This
will enable the typelib marshaler (setup your interface under
HKEY_CLASSES_ROOT and direct the SCM to use OLEAUT32.DLL as the proxy/stub
class object).
If your interface is a custom Vtbl (not oleautomation compatible), then you
must build the proxy/stub DLL and register it.
Peter Partch
Pascal Suter wrote in message <7ktauj$5dm$1...@nnrp1.deja.com>...
Raj
I suppose the problem is related to Marshalling. By default COM supports
standard marshalling. While accessing an Out-of-Process COM object you must
implement custom marshalling. If you don't, you will not be able to access
the interfaces exposed by that object.
Raj
Girish Bharadwaj[mvp]
Huh!!!, I dont understand. All you need to do is to build proxy/stub
dll and register that to make it work in a local server (if using
custom interfaces) else register the typelib. You dont have to have
custom marshalling in any normal scenario. It is useful in cases where
you want to support some special way of moving bytes other than the
ones used by COM runtime support.
On Fri, 25 Jun 1999 23:27:49 -0400, "Raj" <r_c...@ix.netcom.com>
wrote:
Girish Bharadwaj [mvp].
Please do not email queries to me.
Post them in newsgroups.
Thank you.
Alexander Nickolov
--
===============================
Alexander Nickolov, MCP
Panasonic Technologies Inc.
Speech Technology Laboratory
email: agnic...@geocities.com
===============================
Girish Bharadwaj[mvp] wrote in message
<37775adf....@msnews.microsoft.com>...
Andrew Osman
can be contained in a VARIANT, then COM will marshall the data between the
two processes, remote OR local. All that is required is to register the
typelib.
-Andy
Raj <r_c...@ix.netcom.com> wrote in message
news:eVpErP4v#GA....@cppssbbsa02.microsoft.com...
Andrew Osman
> He simply doeasn't understand marshaling.
That's sooooo helpful.
Get off your pedastal.
-Andy
Alexander Nickolov
Standard marshling means usage of proxy at the client and stub
at the server talking over the RPC protocol. The Automation
marshaling in a sense is kind of standard marshaling because
it uses the generic proxy and stub used by IDispatch.
BTW, custom marshaling is on per object basis, not on per interface
basis and means that the object implements IMarshal. COM bypasses
the standard marshaling in this case and uses the object's own
marshaling scheme even if the interfaces themselves have standard
marshaling support.
--
===============================
Alexander Nickolov, MCP
Panasonic Technologies Inc.
Speech Technology Laboratory
email: agnic...@geocities.com
===============================
Andrew Osman wrote in message ...
Andrew Osman
that Automation includes IDispatch and such and makes your object(s)
accessible from VB and other scripting types of environments.
As I understand it, if your COM object doesn't implement IMarshal then COM
will use the Standard Marshaller so long as you use OLE Automation capable
types. So to me Standard Marshalling is equivalent to OLE Automation minus
IDispatch and all the other Automation baggage.
-Andy
Alexander Nickolov <agnic...@geocities.com> wrote in message
news:#fvKqqmw#GA....@cppssbbsa02.microsoft.com...
Alexander Nickolov
>As I understand it, if your COM object doesn't implement IMarshal then COM
>will use the Standard Marshaller so long as you use OLE Automation capable
>types. So to me Standard Marshalling is equivalent to OLE Automation minus
>IDispatch and all the other Automation baggage.
It uses standard marshaling, yes, but first, it is called Proxy Manager, and
second, you don't need Automation compatible types at all. You do need
standard marshaling compatible proxy/stub DLL (i.e. the source generated
by MIDL and complied into a DLL). The Automation marshaling is a variation
which uses the generic IDispatch marshaler for every interface which has
'oleautomation' flag in its IDL definition. The type library which describes
it
is used by the Automation marshaler (e.g. the IDispatch marshaler) to
actually transmit the interface specific arguments for all methods. Since
the Automation marshaler is limited to Automation compatible types, those
are the only types allowed in this scenario. Of course there are limitations
on the standard marshaling, the most severe is that it only allows machine
independent passive types (in fact these are the C types with some
extensions like BSTR and interface pointers) - which means C++ content
is prohibited (void and void pointers are prohibited too). The complete list
is in the MIDL manual.
--
===============================
Alexander Nickolov, MCP
Panasonic Technologies Inc.
Speech Technology Laboratory
email: agnic...@geocities.com
===============================
Andrew Osman wrote in message ...
[snip]