|
Hi everybody, last (I hope) problem.
After I released a beta of my preoject, 4 months ago, the customer asked me to change my COM-calling style.
I used Smart Pointers with CreateInstance, and server registration on both sides. The customer does not want the server to be registered on client machine, so I was suggested to still use Smart Pointers, but now with CoCreateInstanceEx and Attach.
Briefly, it was:
<br />
ISwitchBoardPtr pISB;<br />
...<br />
pISB.CreateInstance(__uuidof(SwitchBoard));<br />
<br />
...<br />
...my code...<br />
...<br />
pISB.Release
now, it seems it has to be:
ISwitchBoardPtr pISB;<br />
COSERVERINFO csi = {0, L"10.0.1.9", NULL, 0};<br />
MULTI_QI qi = {&__uuidof(ISwitchBoard), NULL, S_OK};<br />
HRESULT hr = CoCreateInstanceEx(__uuidof(SwitchBoard), NULL, CLSCTX_REMOTE_SERVER, &csi, 1, &qi);<br />
ISwitchBoard *_pISB = static_cast<ISwitchBoard *>(qi.pItf);<br />
pSB.Attach(_pISB);
In this object I expose several UDTs, even big and complex (imagine a structure that has as one of its fields a SafeArray containing another structure), and when I used the first method, everything worked fine and the customer was happy, but when I started to use the second method, NONE of my UDTs is marshaled anymore. I get crashes in client (while the server keeps running fine, logically) when I try to get as [out] or [out, retval] parameters one of my UDTs.
I'm stuck. The only thing I thought about is that qi.pItf is a IUnknown * type, while my objects expose IDispatch interfaces, but IDispatch is derived from IUnknown, as every interface in COM, so it should work, shouldn't it?
Thanks for your kind help again...
|
|
|
|
|
How you are populating the UDTs? as safearray? If not universal marshaler cant marshal them as UDTS are unnown type for them.
Also register thr type library on the client if you didnt do so.
rgds..mil10.
|
|
|
|
|
How can the use of smart pointers cause problems with marshalling?
The call is made exactly the same way to the server and the type library is still the same. Am I missing something here?
Since you're mentioning IDispatch I guess that the interface in question is declared in the IDL-file as either dispinterface or has the oleautomation attribute set.
If this is the case, then Mil10's comments applies: you cannot pass UDTs through an automation interface unless you convert them into SafeArrays of e.g. char.
The universal marshaller can only handle types that can be represented with a VARIANT.
If you are indeed using a custom interface that doesn't derive from IDispatch you have to deal with the marshalling by yourself and also distribute and register the marshalling dll that contains the proxy/stub.
As I understood your execution environment, the server is located on another machine than the client. This means that the proxy/stub has to be registered on both machines, otherwise at least the marshalling won't work.
Hope this helps
--
Roger
It's suppose to be hard, otherwise anybody could do it!
|
|
|
|
|
Exactly, either use universal marshler compatiable types, ie Safearrays with variants and register the universal marshler's proxy, ie the type library file on the cleint.
Or Go for custom marshaling and register the custom proxy stub dll on the cleint. I dont think this second option is feasible. It will be better to go for the first option of universl marshaling.
rgds...mil10
|
|
|
|
|
This is one of the UDTs I pass (both structures have been declared, in IDL file, with an UUID, I use SAFEARRAY with VT_RECORD and GetRecordInfoFromGuids on both server and client side):
struct RGBValue_struct<br />
{<br />
unsigned int R,<br />
unsigned int G,<br />
unsigned int B,<br />
unsigned int alpha;<br />
}RGBValue;<br />
<br />
struct COM_IVA_Image_struct<br />
{<br />
SAFEARRAY(RGBValue) saPoints,<br />
int rows,<br />
int cols;<br />
}COM_IVA_IMAGE;
the method declaration, in server side, is
HRESULT loadImage([in] BSTR fileName, [out, retval] COM_IVA_Image IVAImage);
and the call, on client side, is
COM_IVA_Image IVAImage;<br />
IVisionEnginePtr pIVE;
<br />
IVA_Image = pIVE->loadImage("2230.tif");
where am I wrong?
thanx again
Morenz
|
|
|
|
|
morenz wrote: where am I wrong?
Hard to say since you haven't told us whether you're using an automation interface or not and what kind of marshalling you're using.
IF you're using the universal marshaller then the COM_IVA_IMAGE structure is unsupported since it's not an automation data type that can be represented with a VARIANT. Even if the members of the COM_IVA_IMAGE structure are oleautomation compatible, the structure is not.
Consider altering the parameter list for the loadImage() function to
HRESULT loadImage( [in] BSTR fileName, [out] long* rows, [out] long* cols, [out, retval] SAFEARRAY(char)* saPoints );
--
Roger
It's suppose to be hard, otherwise anybody could do it!
|
|
|
|
|
ok, I understood, you hit the correct point.
I'm using dual interfaces (I noticed that using or not the oleautomation keyword does not affect things) and I'm using universal marshaling.
One last thing: WHY does it work with CreateInstance? Just because CreateInstance uses the registery-based technique? How can it manage better these UDTs?
Thanks again for your (your and Mil10's) precious help, that was not the first COM I created, but I was never gone so deep in COM architecture...
Best regards,
Morenz
|
|
|
|
|
morenz wrote: I noticed that using or not the oleautomation keyword does not affect things
That's because since it's a dual interface it's implicitly an automation interface.
morenz wrote: WHY does it work with CreateInstance?... How can it manage better these UDTs?
To put it simple: it cannot. Since it's the same interface and the same marshaller this won't change. I suspect that when you used CreateInstance() you had a server registered on the same machine as the client and it was invoked as an in-process server so there was no need for marshalling, hence it would seem to handle the UDTs better but in fact they were never "handled" at all.
But I'm only guessing here.
--
Roger
It's suppose to be hard, otherwise anybody could do it!
|
|
|
|
|
No, I verified several times... The server is registered also in client machine (with /RegServer switch), but it's configured (via DCOMCNFG) to go ONLY remote. To be sure, I referred for my test to some image files there were present only on server machine, and I referred them putting down the entire path when calling server methods. If it was like that you are saying, I should get a "file not found" error, instead it did all that it had to do with no problems at all. Also, if I unplug network cable, I get a "RPC Server Unavailable" error.
Last question: if I decide not to use dual interfaces (therefore using IUnknown instead of IDispatch), can I get rid of this problem? If I decide doing custom marshaling where can I get an example of this technique (that I've never seen before?)
Thanx again....
Morenz
|
|
|
|
|
Sorry Morenz, I haven't done custom marshalling so I cannot guide you in the howto process of custom marshalling.
However, I do know that with custom marshalling you can marshal any UDT you like since you have control of how it's done and transferred through the RPC channel.
I suspect that the howto-part is non-trivial and perhaps that might make you consider still using universal marshalling and automation interfaces.
If you're going for custom marshalling I guess you have to buy a good book about the subject...
--
Roger
It's suppose to be hard, otherwise anybody could do it!
|
|
|
|
|
ok, no matter.
The final decision will be taken by the customer, and it will be based on how SOON they want the project 
In the worst case (custom marshaling) I think I will buy a book and, why not, consider to give a shot in some serious forum, like this...
Thanks for all.
Enjoy
Morenz
P.S. Pardon me, but in your footnote (or signature) you have a typo: you should have "It's supposed to be hard" instead of "It's suppose to be hard"
|
|
|
|
|
Hey!
I was wondering if anyone knows of a way to lookup which com components are installed in Windows XP. I know I can look it up through Visual Studio but I don't want to install that on every system every time I want to check the installed com components.
|
|
|
|
|
Look at the subkeys of "HKEY_CLASSES_ROOT/CLSID" in the registry.
Steve
|
|
|
|
|
Hey good luck,
i have created the sample application for same
see the following code
CoInitialize (NULL);
ICatInformation *pCatInfo=NULL;
HRESULT hr=CoCreateInstance (CLSID_StdComponentCategoriesMgr ,NULL,CLSCTX_INPROC_SERVER,IID_ICatInformation ,(void **)&pCatInfo);
pCatInfo->AddRef ();
IEnumGUID *pEnumGUID=NULL;
CATID pcatidImpl[1];
CATID pcatidReqd[1];
pcatidImpl[0]=CATID_Control;
pCatInfo->EnumClassesOfCategories (1,pcatidImpl,0,pcatidReqd ,&pEnumGUID);
CLSID clsid;
while( (hr= pEnumGUID->Next( 1, &clsid, NULL ))==S_OK )
{
BSTR bstrClassName;
OleRegGetUserType (clsid,USERCLASSTYPE_FULL,&bstrClassName);
CString strControlName(bstrClassName);
m_list1.AddString (strControlName);
}
pCatInfo->Release ();
CoUninitialize ();
Knock out 'T' from CAN'T
You 'CAN' if you think you 'CAN'
|
|
|
|
|
Can someone explain me the major differences between an ActiveX control
and a COM dll in the context of accessing it from a web page using some
script.
For example, I need to get the MAC ID of the machine from within a web
page. So I thought of developing a COM dll, pack it in a cab using
cabarc, and call the method from within a script in the OnLoad of the
page. Do I need to actually go for creating an ActiveX control instead
of developing the COM dll? Is there any problem with using a COM dll?
Is there any additional advantage in going for ActiveX instead of COM
dll? Infact both the approaches worked fine on my development machine
!!
Thanks in advance.
|
|
|
|
|
If you dont need any UI features, then ofcourse you can go for a simple com component. Activex is for putting UI stuff.
rgds..mil10
|
|
|
|
|
How many kinds of DLLs are there? one that we are able to use with VB, ASP ect. The one which we are able to use with C++ but not VB, Can we create a DLL that is not COM based, and use it in VB? And what kind of Dlls we find in the windows system directories? Can any one brief on it?
NULL
|
|
|
|
|
For more information on dll's you can refer the bottom link
http://www.thevbzone.com/l_dll.htm#DLL%20TYPES
Vision is Always important and so is your ATTITUDE.
Wishes.
Anshuman Dandekar
|
|
|
|
|
Hi,
In one of the code snippets i have seen this.
It looks something like this.
interface IA;
interface IB;
class CCOMTest : public IA,public IB
{//Some code here
}
Inorder to get the pointer to IA,
the code looks something like this
static_cast<IA*>this;
why static_cast ??
what happens if i do (IA*)this ???
can anybody clarify my doubt??
I am a beginner to COM.
Thanks in Advance.
Appu
|
|
|
|
|
this is available in this codeproject site itself.
visit : http://www.codeproject.com/cpp/static_cast.asp
^-^
@|@
- redCat
|
|
|
|
|
"Normal casting" (a.k.a "C-style" casts) should be avoided. If you need to cast always use static_cast, const_cast, reinterpret_cast or dynamic_cast. There are many reasons, some of which are that with these "function-style" casts your cast is:
1. Explicit (in intent).
2. Visible.
3. Checked for safety by the compiler.
There are still many people who use C++ but, for one reason or another, use "C-style" casts: These people are making a mistake. If you've been a maintenance programmer for a few years and seen the havoc caused by vague (in intent) and hard to spot or grep for casts you will probably agree. Some people argue that the new casts are ugly. That is intentional: casting, in general, is an ugly and dangerous practice and more often then not indicates a design flaw in your code. Casts should be ugly.
Steve
|
|
|
|
|
Hi All,
Can anybody explain the need of default interface in COM?
I am beginner to COM.
Thanks in Advance.
Appu
|
|
|
|
|
hi ,
i guess you are asking about IUnknown.
if so, this interface contains the 3 basic methods that are pillars of COM technology to work.
Interface is nothing but the abstract base class in c++.
it means that ultimately all components are required to implement these three methods and simply it is generalized in this IUnknown interface.. that's it
- cheers
redCat
^-^
@|@
|
|
|
|
|
Thanks for the immediate response.
But my doubt is different.
if we look at the idl file that is generated in a COM application we could find something like this.
[default] interface ICOMSample;
Will this [default] be associated with all interfaces. if not, why??
and What is the need of this.
Appu
|
|
|
|
|
[default] is an indicator to scripting languages such as VBScript which interface is the default one. Such scripting languages cannot navigate to alternate interfaces, so in effect they can only access the single interface marked [default]. This attribute is saved in the generated type library but doesn't otherwise affect the generated code.
Visual Basic 6.0 can access non-default interfaces but this feature isn't commonly used. You simply create a variable of the interface type (e.g. Dim o As IOtherInterface) and assign an existing object to that variable - if the class implements that interface, VB assigns the variable, and if not, an error occurs. Similar behaviour occurs in .NET languages.
If all your clients are C++ clients you don't need to worry about this attribute.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
