|
I'm sorry if my question is a bit doom. I'm new to COM. I read the Developer's Workshop to COM and ATL by Andrew W. Trolsen. It's quite good but I doubt on something.
I don't know why MS must have DLLGetClassObject to return iclassfactory. IMHO, returning iunknown inside the coclass should be easier, so that the developer can query interface immediately.
If you know why, please enlightening me in a simple and clear answer, coz I'm very new to COM.
|
|
|
|
|
|
Thank you for promptly reply. Your article is really good. But I don't know why it must be IClassFactory. Why not be...
hr = CoGetClassObject(CLSID_CoCar, CLSCTX_INPROC_SERVER,
NULL, IID_IUnknown, (void**)&pUnk);
hr = pUnk->QueryInterface(IID_ICreateCar, (void**)&pICreateCar);
or Implementing CreateInstance in IUnknown
instead of letting CoGetClassObject create IClassFactory and then use IClassFactory to create IUnknown.
Thank you
|
|
|
|
|
doromoji wrote:
instead of letting CoGetClassObject create IClassFactory and then use IClassFactory to create IUnknown.
Because that's how COM is designed. The class factory is a mandatory intermediate step.
Class factories were designed to allow client apps to create multiple instances of an object, using the IClassFactory interface. In practice, I have yet to see a real world use of that design.
So, while you are right in the "direct use" you suggest, I am afraid you can't do much about it : the COM library is a native library of the operating system. Imagine it would break hundreds of thousands of real world COM apps only to satisfy the need of one customer (or several).
Besides that, MS is not investing in COM anymore. The .NET CTS provides the best of COM without the hassles.
|
|
|
|
|
[quote]
Class factories were designed to allow client apps to create multiple instances of an object, using the IClassFactory interface.
[/quote]
Not only. The main reason is that the EXE server must expose something to have access to him. It is a class factory, but no object itself.
For DLL server it is possible to solve without a class factory but it was done with compatible way.
With best wishes,
Vita
|
|
|
|
|
Thank you all.
|
|
|
|
|
Is ODL an alternative to IDL to provide interfce definitions
Also can I compile it with MIDL and get the necessary header for the interfave
|
|
|
|
|
I would like to take an existing application that I created and create and object so I can embed into other documents. For example in Microsoft Word. I can insert a Excel worksheet object into word (Insert>Object) and toggle between the two applications. Any ideas on how I can achieve this.
Thanks
|
|
|
|
|
In the most generic way, the answer is you have to implement the object container. As a start-up code I would like to recommend you the ActiveX Control Test Container sources (I guess available somewhere on microsoft msdn site) or sample called I guess VBLite (described in article Extending ATL 3.0 Control Containment to Help You Write Real-world Containers)
hope this helps
|
|
|
|
|
Hi all,
Can anyone point me in the right direction of information about using the Excel grid in a VC++/MFC app? I'm just looking to get the grid on a view / dialog, maybe manipulate some rows / columns (via code), etc.
Is this even doable?
Dylan
"In meetings, the person who is least competent usually does the most talking. Talking is a direct substitute for competence, at least in the minds of other people. Five minutes after you leave a meeting, you won't remember what anyone said but you will remember who did most of the talking. Withing a day your mind will translate that into a notion that the talker was unusually knowledgeable" - Scott Adams, Dilbert and the way of the weasel
|
|
|
|
|
Not sure you could get just the grid part. What I've done in the past is use the ability to embed an OLE object into a view. You can use the component in-place, and also get it's IUnknown interface. From there, you can get a dispatch interface and navigate Excel's object model to pretty much do what you want.
If all you want is a grid, on the other hand, then look no further than this site, as Chris' excellent control. I believe others have produced various flavours such as an ATL implementation, although I haven't used those.
I have used the original quite extensively in some form filling apps, as my about boxes testify... "Portions (C) Chris Maunder" etc.
Steve S
[This signature space available for rent]
|
|
|
|
|
I created an OCX control in a dialog box, using the class wizard, created a member variable etc. and it's all working fine. However, I need to (dynamically) set some of the parameters that are initialised when the object is created, so I'll need to control the creation of the OCX object directly from my program, rather than let the class wizard handle it all for me.
Does anyone know how I can hook into this?
Ta,
Debbie
|
|
|
|
|
You can use ATL's CreateControl() API to create OCX in a container app.
|
|
|
|
|
Reasonable Developer
i wanted to download the SDK of Microsoft Project, i try my best but fail(it give overview of MS Project 2002) pls help me. So nice of u
Note
i have already test it but it was just an overview of sdk whereas i have to integrate the MS Project & therefore i need to download the complete sdk, now pls try for it & if u find any solution inform me
So nice of u OK
|
|
|
|
|
Go to msdn.microsoft.com and follow the links to the download page.
Christian
No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
Appologies for not posting this on VC++ message board ( the link was timing out)
I am trying to call a DLL written in Fortran from my VC++ application. Everything works fine, but when the Fortran DLL runs into trouble (some exception occurs in the FOrtran DLL) I see a dangerous looking Dialog Box, given the stack trace and the VC application simply exits. I have tried enclosing Fortran DLL function call with both try-catch and __try__except blocks, but the code in the catch/except never gets executed. Is there any way to catch Exceptions raised in FOrtran DLL in the calling VC++ applications.
Any help will be greatly appreciated.
cheers,
kashif manzoor
peace to all
|
|
|
|
|
try/catch and __try/__except blocks are setting per thread exception frames , so your Fortran dll may spawns another threads that may throw the unhandled exceptions you are faced.
Try to set a proccess wide exception filter that will exceutes as the last recover to the unhandled exceptions that may be thrown by your dll.
the key function is the Win32 SetUnhandledExceptionFilter function.
I hope it works for you.
AbuMalek
|
|
|
|
|
Hi fellows,
I would like to have COM object pooling. Therefore, i thought that if i overwrite the CComObject::Release method then i get what i need.
Since CComObject is derived from any COM object and it is the one that implements the IUnknown methods (such as Release), i thought to have explicit specialization of template CComObject.
However, i get compilation error when i do the following:
template<>
class CComObject<CMyCOM> : public CMyCOM
{
...
}
error C2934: 'CComObject' : template-class-id redefined as a nested 'class' of '<unknown>'.
How can i have my CComObject specialization?
Thanks,
Dudi
|
|
|
|
|
I know this is half an answer, but can't you use COM+ object pooling? It's fully automatic, stable and you only need to have a free-threaded component.
My latest article:
SQL Server DO's and DONT's[^]
|
|
|
|
|
No, i can't use COM+. I am trying to do it myself by overwriting
Release method of CComobject.
However, i fail to have template specification.
|
|
|
|
|
Hmmm... Maybe this is a case for COM aggregation. It seems easier to control AddRef/Release by creating a second component that aggregates the first. It can be done in such a way that's almost transparent to clients and this will ease turning on/off the pooling behaviour. I know it's more a workaround, I don't have a solution for your specific problem, but IMHO it would be a more elegant way of implementing this kind of functionality.
My latest article:
SQL Server DO's and DONT's[^]
|
|
|
|
|
Maybe I am reading this wrong, but if you want to overwrite the Release function provided by CComObject then you should be creating a class that inherits from CComObject and overwrite its Release function. In the code example you provided it appears that you are doing it the other way round.
Instead of
template<>
class CComObject<cmycom> : public CMyCOM
Try
template<>
class CMyCOM<> : public CComObject
This way CMyCOM provides all features of CComObject except those that you overwrite.
|
|
|
|
|
You didn't understand me.
When you work with ATL to create COM objects, you should know that ATL defines a template class, called CComObject, that derives from your COM class.
CComObject is the most derived class which implements AddRef, Release and QueryInterface methods. (Look at atlcom.h)
Therefore:
1) I can't inherit from CComObject because it is derived from my COM class.
2) I tried to have explicit specialization
template<> class CComobject<CmyCOM>:public CMyCom{...} .
But i get error C2934: 'CComObject<class CMyCOM>' : template-class-id redefined as a nested 'class' of '<Unknown>'
What does the error mean?
|
|
|
|
|
I am not sure what the error means, but you sure have me thinking now...
Is CMyCOM an ATL COM class or just a C++ class?
Also it seems you are creating CComObject. But that class already exists.
Also per MSDN :
CComObject implements IUnknown for a nonaggregated object. However, calls to QueryInterface, AddRef, and Release are delegated to CComObjectRootEx.
So to achieve what you want, i.e., overwrite Release, you could derive a class from CComObjectRootEx, and then make your COM classes inherit from the derived class rather than CComObjectRootEx. Or something like that
Just random rambling thoughts.....
|
|
|
|
|
CMyCOM is an ATL COM class.
This class is derived from CComObjectRootEx so i can overwrite 'InternalAddRef' and 'InternalRelease' methods.
Now, take a look at CComObject::Release():
STDMETHOD_(ULONG, Release)()
{
ULONG l = InternalRelease();
if (l == 0)
delete this;
return l;
}
This is where a decision is made according to the reference counter. I can overwrite InternalRelease but it won't help. I must change CComObject::Release so that if the refernce counter is 1 then the object should be return to the pool.
|
|
|
|