|
Well, I can't register *anything*, but the other programmer in our group can register even the new DLLs, so it's looking like a complete wipe/reinstall is going to be the result (goddamnit).
------- sig starts
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Perhaps you've already started the reinstall process, but you could try this first....
You mentioned an .rgs file, which usually means that you need another COM server that ships with ATL, namely the ATL Registrar server.
Have a look in the OLE/COM viewer to see if it's registered.
You should find it under its ProgID, ATL.Registrar. The .dll is atl.dll and can usually be found in the system32 dir.
If the Registrar is not registered, it could explain the error code about a missing module.
Give it a shot and let me know, will you?
--
Roger
It's suppose to be hard, otherwise anybody could do it!
|
|
|
|
|
I haven't started it yet -our network guy wants to do it, but he's on a family emergency leave for the rest of the week.
I'll look for that when I get to work this morning, but...
One of the symptoms of the problem is that when I run regsvr32 with no parameters, it takes almost a minute for it to come back with the expected error message. During that time, an additional instance of regsvr32 are spawned several times (it appears and disappears in the task manager process list).
On everyone else's machine, it comes back almost immediately with the expected error message. I honestly think my machine is just hosed up... :/
------- sig starts
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
John Simmons / outlaw programmer wrote: I honestly think my machine is just hosed up...
Well, I suppose you're the better judge of that...
It's suppose to be hard, otherwise anybody could do it!
|
|
|
|
|
Hi Gurus,
What is the difference between COM and ATLCOM..?
which is more powerful ??
Knock out 'T' from CAN'T
You 'CAN' if you think you 'CAN'
-- modified at 9:00 Thursday 4th May, 2006
|
|
|
|
|
hi,
according to my understanding
COM is a specification to write libraries that can be reused among languages.
ATL is a Wizard or Library to create the components.
there is nothing called ATLCOM.
^-^
@|@
- redCat
|
|
|
|
|
Do you have any idea about steps to be follow to write the COM ..?
Thanks in advance.
Knock out 'T' from CAN'T
You 'CAN' if you think you 'CAN'
|
|
|
|
|
COM is the famous Component Object Model.
ATL is the Active Template Library used for creating COM components, ActiveX controls and so on.
Regarding ATLCOM the only thing that comes to mind is the .dll that contains the ATL implementation, atlcom.dll.
For more information about COM, Michael Dunn's article is an excellent starting point and you'll find it here[^].
Hope this helps
--
Roger
It's suppose to be hard, otherwise anybody could do it!
|
|
|
|
|
Thanks Roger
I got it now
Knock out 'T' from CAN'T
You 'CAN' if you think you 'CAN'
|
|
|
|
|
Hi All,
I'm getting a link time error error LNK2001: unresolved external symbol <clsid>. I'm not able to get what is the cause behind it.
Just do it
|
|
|
|
|
the .lib file is not there in the link path.
or you might have declared a function but forgot to define it.
simple see the function name in the linker error.
^-^
@|@
- redCat
|
|
|
|
|
leanmean wrote: I'm getting a link time error error LNK2001: unresolved external symbol . I'm not able to get what is the cause behind it.
Ummm, an unresolved external perhaps...;)
Seriously, you have to tell us more.
An 'unresolved external' means that you somewhere makes a function call to a declared function, but the definition of the function cannot be found by the linker.
In other words: you may have forgotten to add the source file that contains the function implementation to the project so it won't get compiled.
If this doesn't help...
- is the function a part of an external library or
- have you written the function by yourself
Hope this helps
--
Roger
It's suppose to be hard, otherwise anybody could do it!
|
|
|
|
|
i am using a vc++ Automation client to access the methods of a component.
the Component is local server.
i need to call 3 methods from this component. First function f1, i am able to call,
for the second function f2, i am getting this error in HRESULT.
i am not doing any store operation in that method, and the method should return me an xml.
i tried to use the services using IMyInterface* . it seems working fine.
but if i try to access using IDispatch, i am getting the problem.
Please give me some clues if any of you have came across this problem , just help me.
- thanks
^-^
@|@
- redCat
|
|
|
|
|
hi,
i myself has fixed the problem. i am passing a [out]BSTR* parameter to this method. and it is not initialized. after assigning BSTR a = NULL; it seems working
- bye
^-^
@|@
- redCat
|
|
|
|
|
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"
|
|
|
|
|