I believe CA::QI -is- calling the non-delegating query: m_pUnknownInner is a pointer to the non-delegating version of IUnknown. When an aggregatable object is created, the new object will return the non-delegating IUnknown: this is the one and only time that an object will return the non-delegating interface, rather than the "usual" delegating interface, when IUnknown is requested. This is why the aggregating parent object -must- query for the IUnknown interface when it's calling CoCreateInstance() for the child object: if it didn't ask for IUnknown at create-time, then it would never be able to get the non-delegating interface....
Note there's certainly other ways of doing aggregation, too: take a look at Don Box's method in Essential COM, too....
HELP! I followed instructions given in Microsoft on-line help Article ID Q173974 for adding MFC support to an ATL EXE Project but I get the following build errors in the CServiceModule:
error C2660: 'Init' : function does not take 2 parameters
error C2065: 'IDR_ServerS2B' : undeclared identifier
error C2660: 'UnregisterServer' : function does not take 1 parameters
error C2660: 'RegisterServer' : function does not take 1 parameters
error C2039: 'StartMonitor' : is not a member of 'CServiceModule'
error C2065: 'dwPause' : undeclared identifier
I *appear* to have run into a limitation (or perhaps a bug?) in the #Import statement used to import a type library in Visual C++. Since I can find no documentation on this, I was hopeing that one of you might be able to shed some light on my problem.
Imagine that I have two projects. One automation server, and one client.
1) The Automation server
The server is defined by an .idl file containing several (dual) interfaces (around 20). Among all those interfaces I have a total of 499 functions defined.
2) The Automation client
The client uses the #import statement to import the type library (.tlb) created by the server.
At this point, everthing works fine. The #import <.tlb> runs smoothly and the client can access and use the functionality of the server without a problem.
Now... If I add another function to the server (function 500) suddenly the client refuses to compile.
I've determined that the problem is not simply a syntax problem. It appears to me, that the #import directive has a fixed limit of 499 functions that it can handle before it chokes. Can anyone confirm this?
Looking at the client-generated implementation files (*.tlh and *.tli), I find that the output generated for the two different versions (499 functions vs. 500 functions) is quite different. The *.tlh file for the 499 function version (the one that works) contains an #include statement at the bottom to include the *.tli file. In the 500 function version, the #include is replaced by:
#pragma start_map_region(<*.tli file and path>)
__declspec(implementation_key(1)) short ( );
__declspec(implementation_key(1)) short ( );
... // functions 3 to 498 excluded for brevity
__declspec(implementation_key(1)) short ( );
__declspec(implementation_key(1)) short ( );
I'm willing to entertaint the argument that I simply should not ever create (much less import) a type library containing 500+ functions. However, I would still like to find out what the story is with this, if only to satisfy my curiosity.
Also, I can find no documentation on either the "#pragma start_map_region" or "__declspec(implementation_key())" statements. (I know what #pragma and __declspec are . Can anyone tell me what these are and what they do?
When the client calls the member function of the interface in the exe server,the following assert is displayed in the dialog .
"The value of ESP was not properly saved across a function call .
This is usually a result of calling a function declared with one calling convention with
a function pointer declared with a different calling convention
I don't know how to solve the problem .Could anyone help me?
ESP is the stack pointer register E stands for 32 bit (as opposed to the 16 bit pointer on the 80286 many years ago.
The error message is usually correct, but sometimes something really bad happened like you whacked something on your stack (buffer overrun), and sometimes you can get this message by stepping over code in the debugger using "set net statement".
If you know that you haven't been writing to memory off the end of an array thats a stack variable, take a look at the Docs on "calling convetions". what typically happens in these cases is that you have 2 funtion prototypes that declare the function to have differing calling convetions. You need to make sure that the person who implements the function agrees with the person who calls the function as to things like where function arguments are passed on the stack or in registers, etc.
I am developing a product on COM and i want to have a seperate dll which provides error handling features.
The existing existing framwork consists of one dll and the exception handling is carried out in the same dll using atlreporterror() and the customised HRESULTS are generated using MAKE_HRESULT.I want to have a seperate dll which is to be implemented using Monikers.My idea is to store all the product specific error codes in a table in the database and my error handling api should retrieve the appropriate error messages from that.
My question is whether it is useful to build such a framework using IMoniker or you have any suggestions for me regarding this?
I’ve been trying to get my mind around the following issue in COM: The use of the [dual] parameter when defining interfaces. I’ve read all (....well a lot of) the text on it, but haven’t really found my answer.
Let me tell you what *I* understand (correct me if I’m wrong):
1. dispinterfaces are the same as interfaces inherited from IDispatch.
2. Interfaces derived from IDispatch use Invoke to call methods, while IUnknown derived interfaces use VTables.
3. Using [dual] makes an interface able to use both VTable and Invoke.
....so here comes the problem.
If I define an interface (IDispatch derived and NOT using [dual]) and defined it as a [source] in a coclass then VB is happy to see the events. Yippie! If I use the [dual] parameter on that interface then VB does not like me and won’t see the events?
So my first question is WHY DOES VB not see the events if it is marked as [dual]? Secondly WHY would one ever really use the [dual] parameter….I don’t see where it is useful?
Anyway….any (helpful) comments would be appreciated!
I'll try and help with what I understand about disp and dual interfaces.
1. Disp interfaces are not derived from IDispatch, they are IDispatch. The automation client will only be aware of the disp interface, and this wil be the only means of communication between automation clients and your object.
2. Disp interfaces will use invoke to call methods of your object, and they will use GetIDsofNames to discover at run time the methods and properties exposed through the IDispatch interface. IDispatch is in fact derived from IUnknown, however, as are all COM interfaces. So, you are in fact using a VTable if you use IDispatch, but you are using a VTable to the IDispatch methods, not the specific methods of your interface (IMyObject or whatever).
3. Using dual means that your object will implement an IDispatch interface as well as a custom interface. Methods of your object will be available both through the IDispatch interface and through its custom interface. Methods accessed through the custom interface will be accessible directly through the interface pointer (VTable), while methods accessed through the IDispatch will have to be accessed through the slower Invoke method of IDispatch. The invoke method basically just imposes the same signature on all of the methods of your object by packaging all parameters to the method in a variant array. So you lose speed with the dispatch, and also sacrifice a little bit of type safety, in that it's no longer possible to check the parameters to a method at compile time, so it's possible to send the wrong number and types of arguments to a call to IDispatch::Invoke, and get a return value of E_INVALIDARG. A single interface does not use both invoke and a direct VTable. The IDispatch interface exposed by your object implements the Invoke, etc., while the custom interface(s) expose whatever methods they wish though the VTable.
Event source interfaces are pure disp interfaces by convention, not dual or custom. The event source interface should be a separate disp interface. Note that this is an outgoing interface, so this means that the event interface is published by your object, but the methods are implemented by the object that wishes to receive the events. When your object fires an event, it is actually calling a method of the source interface implemented on the receiving object. You may implement multiple event sources on a single object, but I think usually one is probably enough.
Using a dual interface allows C++ or other custom clients the ability to access the faster custom interface of your object, while at the same time allowing automation clients the ability to use your object through its dispatch interface (things like VBScript). When you use the dual interface, there's no extra work required on your part to support IDispatch, so it's basically for free. If your object will never be used through an IDispatch interface, there is no benefit to using dual interfaces, but they offer the most flexibility and portability.
I want to be able to embed a text file into a rich edit control when the operator drags a file into the control. At the moment it appears that a link is inserted into the rich edit control rather than the file itself. This means if the original file is deleted the copy of the file in the rich edit control cannot be edited. Can anybody point me at an example of how to do this. I have got as far as implementing the callback interface so that I know when a file is being dropped but I dont know where to go from there. I have tried looking through MSDN but I have been unable to find a good explanation of how the facilty works.
"With the release of Microsoft® Windows® 2000, 64-bit Edition, Component Services provides developers with the ability to configure a COM+ server application as an NT service and to implement the service as a COM+ server application by using the Component Services administrative tool."
only 64-bit edition?
why not 32-bit edition?
there is no way?
I want Always Running and Automatically start my component when reboot
If you need a utility that generates a windows help file automatically from
a type library, you might want to take a look at Oberon TLB Tools utility:
This utility includes 3 tools:
TLB2HLP - generates a complete WinHelp project containing .rtf, .cnt, .prj,
and other files ready to be compiled into a .hlp file. The .rtf file
contains help topics on each objects, method, properties, etc. with
descriptions, place holders for code samples, etc. A good start to create
full online help for a COM object model or ActiveX control properties.
TLB2HTML - creates an HTML file containing all type information from a type
library with cross-references, object index, and so on...
TLB Compare - compares two type libraries and writes differences as an HTML
You can find examples of how each of the tools work on the web page given
I hope this is helpful...
Do you still use a stopwatch to track your project time?
Why not try a completely automatic time tracking and billing
application for Windows - VAKCER Project Tracker v2.1?
Get your free trial copy today at http://www.vakcer.com
I need to detect if a local server is running. I do not have any reference to it, so I can not detect if the server is running by just calling a method of one of it's interfaces. If I would use CoCreateInstance I still would not know if the server was active before I called it as I would launch it myself. Does anyone know a sollution for this problem?
I have written an ATL com dll that manipulates some data, but now I want to add a Dialoge to the Dll to display the data ect... I have gon through the wizard and inserted an ATL dialoge but I am not too sure what I have to do now. It does not have an interface or anything like that so how am I supposed to display the dialoge from the calling application. How do I add any of my com objects to the dialog class, its doen't seem to like it at the moment.
If anybody has any any demos that would be great.
just in case anybody noticed - I added this to the VC++ thread, I think it was a cry for help !!
I am creating a COM component in Vc++ and it is going to be accessed from a Web Page. I have a method
in this Com component which is set up to return a result and error.The IDL looks something like this.
I am able to sucessfully get the value when I make the call in VB/aSP
rtval = obj.myMethod(In,out)
But the value of "out" does not change it stays the same value that it was set before the call inspite of me chaning it inside the COM component. Do I need to do anything special to get the value out. I checked the web but they do not have any samples for IDL constructs [out] or [in,out]. Please let me know if anybody has tried it or how to get the results.
Is it possible to have developer studio regenerate my activeX control wrappers, after I make changes to them (add properties and events), short of totally removing the controls from your project and then reinserting them? I am writing the controls using ATL (beginner) and my projects are MFC based. The generated code says the following comment:
// Machine generated IDispatch wrapper class(es) created by Microsoft Visual C++
// NOTE: Do not modify the contents of this file. If this class is regenerated by
// Microsoft Visual C++, your modifications will be overwritten.
// Dispatch interfaces referenced by this interface
To build a simple messenger system, you basically need to program a server and a client (like the IM that you download and install)
The server is listening for messages from the clients. When it receives a message from a client, it forwards it to the right client. The clients listen for messages from the server, when they receive them they alert the user.
It's not that hard to build a simple message system in for example Visual Basic or Delphi, what you have to learn is how to use network sockets. I would recommend you to buy a good book on it, usually you can get enough code from it to create a basic message application.
Henrik Sternberg, Consultant
Cambridge Technolgy Partners, Germany
My employer has at last acknowledged the need for COM/DCOM skills within the company
Unfortuantely only to the level of letting me buy a book
Can anyone reccommend a single book for getting started with COM/DCOM. The book needs to be gentle enough to introduce a COM novice, but advanced enough to be a useful reference manual for when I actually start using COM/DCOM.
Ooh, I'm hard-pressed to come up with a -single- book that suits your needs, but I'll go just a bit out on a limb and suggest _Inside_COM_, by Dale Rogerson. This book is, for me, the best introductory book on COM, and it was the -only- book I used for years (until I started writing my own itty-bitty COM ports to non-MS platforms). For learning COM, I can't reccomend the book too strongly, because it's both a very concise and easy-to-understand book on the fundamentals, and it covers the true goings-on at the binary level, rather than just glossing over those details: D.R. has a great way of describing these fundamentals in such a way that it all seems quite easy to implement - and it doesn't take too much longer to "get it." (Yes, there was a lag between implmentation and "getting it," but this seems to be the MO with COM developers.)
But, there's two major caveats. First, Rogerson devotes few pages in _Inside Com_ to DCOM. Basically, he covers pretty-much just the minimal to code and use COM objects over a remote network using DCOM, but that's about it. Actually, I haven't used DCOM, so he may cover it to as big an extent as necessary, but I somehow doubt it. Second, if you're going to be coding in Visual Basic or Java, or just building "turnkey" ATL COM objects, then Rogerson's book is probably too low-level: given the constraint of one book, I'd probably try find one that more focuses on the COM Wizards and such....
But, all that being said, _Inside_COM_ is a great book with which to get started - and you'll probably come to the reasonable conclusion that "one book for all COM" probably isn't the way to go (didn't the Bible have over ~30 books?). If that hits you, then I'd quickly run out and get Don Box's _Essential_COM_. Don Box is the Johnny Appleseed of COM technology, and his book can help grow your understanding of COM by leaps and bounds. In many ways, Box takes off where Rogerson stops: he focuses more on the distributed aspects of COM, as well as optimized coding strategies that may lead to higher performance software.
Finally, the web is also a great source of COM info - you can't miss wonderful articles like The COM Programmer's Cookbook, and Smart Pointers Considered More Harmful (or whatever it is called). These papers, and many more, are available on the web - and at the right price (free).
I am desiging an ActiveX control.
It is working fine when it is placed in the word document.
But if user selects "design mode" , which is there in the MSWord,
the control is getting selected and when he double clicking on it,
it is going to VBScript mode.
This behaviour should not be there for my control.
Without using #import in the source code of client side , I want to get the interface point from the com server during the running of client .
For instance , through the menu operation , I locate the file which consists of the com-object .Then how can I get the interface point? The com-object does not implement the interface of IPersistFile.
An ATL component control(intended to work with Excel and Word) is working in Win 95/98 but not working in WinNT. when i tried to debug it, control is not coming into the program even into the OnDraw(),even MessageBox() is not getting displayed with Excel. but it's working fine with Word. Please help me