|
1. Because it is base COM API function.
2. First argument provides enough information for marshaling.
3. MS is exception to its own rules 
|
|
|
|
|
IMiracle wrote:
HRESULT AllocaConnect([out, retval] void * p_pclMid);
should be
HRESULT AllocaConnect([out, retval] void ** p_pclMid);
--
If I had the ability to smooth talk like John Simmons, this post would be less sarcastic and more to the point.
|
|
|
|
|
Hi all.
I am looking for a treeview/listview hybrid. There are many implementations using MFC, but for WTL I've only found the CTreeListView by Bjarke Viksøe[^], which is quite buggy. I am convinced that there are more implementations out there... TIA.
Regards
Thomas
Sonork id: 100.10453 Thömmi
Disclaimer:
Because of heavy processing requirements, we are currently using some of your unused brain capacity for backup processing. Please ignore any hallucinations, voices or unusual dreams you may experience. Please avoid concentration-intensive tasks until further notice. Thank you.
|
|
|
|
|
Take the best MFC one you can find and port it to WTL.
All us WTLies will be thankful.
/Magnus
- I don't necessarily agree with everything I say
|
|
|
|
|
Hello,
I was wondering if anyone knows how to pass paramaters that aren't supported by Automation?
For example if I am trying to pass the types "LONGLONG" and a "GUID" in a COM object that supports
automation, but automation doesn't support these types. Is there a solution that I can follow to implement these?
I am using visual c++ 6.0 within a windows 2000 environment.
Thanks for any ideas or help.
|
|
|
|
|
Your COM object supported automation can not support the "LONGLONG" and "GUID" types because they are not OLE-compatible types. It's impossible.
Though you are able to pass these values as a "struct" (or UDT) type which is OLE-compatible.
With best wishes,
Vita
|
|
|
|
|
Thanks for the advice! I was pretty sure that Automation couldn't pass those types but it is always good to hear it from someone else.
I convert my GUID to a bstr before I pass it through now, and will have to try the UDT approach with the LONGLONG.
Thanks again for the reply!
|
|
|
|
|
If I increment a version of a COM control, would it follow that I must change the uuid as well?
In other words would I change my interface definition from this:
vi_progid("GZTW.Tips.TipOfTheDay"),<br />
progid("GZTW.Tips.TipOfTheDay.1"),<br />
version(1.0),<br />
uuid("E89258B1-A73E-4141-9E0F-64F5D056B1AC"),
to this:
vi_progid("GZTW.Tips.TipOfTheDay"),<br />
progid("GZTW.Tips.TipOfTheDay.2"),<br />
version(2.0),<br />
uuid("NEW UUID HERE"),
And then publish for users the new version dependant program ID as well as the new UUID?
(I know there are many other issues regarding this from the end users point of view, It's just that I noticed if I don't change the UUID, the registry contains keys for both versions with the same UUID)
|
|
|
|
|
I would say 'yes' since that's what I do usually but the default progid 'GZTW.Tips.TipOfTheDay' will give same result than 'GZTW.Tips.TipOfTheDay.2'. And don't forget, you should not change any version 1.0 function index value and/or parameters.
If it ain't broke, let's fix it anyway...
|
|
|
|
|
I just noticed in Visual Studio 7.0 Microsoft has included two versions of comdef.h. The problem is they are completely different, what is the purpose of this? If you just #include <comdef.h> you won't get the one you want..
The first 1 is in
C:\Program Files\Microsoft Visual Studio .NET\Vc7\include
and the second one is in
C:\Program Files\Microsoft Visual Studio .NET\Vc7\PlatformSDK\Include
Just curious...
|
|
|
|
|
The one included with the compiler is a strip down version. The one in the platform SDK is the full blown one.
Starting with VC7, Microsoft has tried reasonably hard to remove Windows platform include files from the compiler include directory. Why is COMDEF.H still in the compiler include directory? I have no idea.
As long as the platform SDK include is listed prior to the compiler version, you will get the platform SDK one.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
|
Add a suitable comparison operator to A:
struct A
{
...
bool operator<(const A& r) const
{
return nNum<r.nNum;
}
}and then just use std::list::sort.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I cover this at length in my article on functors.
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
|
|
|
|
|
Hi fellows,
I would like to have explicit specialization of class template CComObject
in ATL.
The reason for this is that i would like to have COM object pooling.
Therefore, if i could overwrite the CComobject::Release method then i have what i need.
However, i get compilation error when i do the following:
template<>
class CComObject<CMyCOM> : public CMyCOM
{
...
}
error C2934: 'CComObject<class cwasterecord="">' : template-class-id redefined as a nested 'class' of '<unknown>.
How can i have my CComObject specialization?
Thanks,
Dudi
|
|
|
|
|
Can't you do this instead?
class CMyCom:public CComObject<CMyCom>
{
...
...
};
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
No i can't, since CComObject derives from any COM object and it is the last derived class that implemenets the IUnknown methods (AddRef, Release and QueryInterface).
I thought that if i write explicit specialization for CComObject then i can get what i want.
|
|
|
|
|
But, if I'm not wrong, IUnknown methods are virtual, you can safely override them.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Yes i know, but i am afraid that somewhere else in ATL code there is
a pointer to CComObject (the most derived class) so i want to be sure that
every call to Release will be to overwritten one.
|
|
|
|
|
Ok, now I think I know what you're after. You can arrange things by laying down the following hierarchy:
template <class ThreadModel> class CMyComRoot: public CComObjectRootEx<ThreadModel>
{
};
class CMyCom: public CMyComRoot<ThreadModel>, public CComObject<CMyCom>
{
};
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
My COM object can overwrite InternalRelease. However, CMyCOM can't inherit from CComObject. On the contrary, CComobject inherits from CMyCOM.
If you look in <atlcom.h> you can see that CComObject derives from a COM object. It is the most derived class.
ATL sometimes works with the pointer to CComObject<> .
Therefore, i have to define explicit specialization to that template.
What is the meaning to:
error C2934: 'CComObject<class cmycom="">' : template-class-id redefined as a nested 'class' of '<unknown>'?
|
|
|
|
|
From the end of your post to the beginning
error C2934: 'CComObject' : template-class-id redefined as a nested 'class' of ''?
Basically, it means that you cannot specialize this, I guess because full specialization implies instantiation, and this can't be done (the same way as CComObject<CComObjectRoot> cannot be instantiated directly).
My COM object can overwrite InternalRelease. However, CMyCOM can't inherit from CComObject. On the contrary, CComobject inherits from CMyCOM.
So, if I' understanding now your intention, CMyCom is meant as a replacement for CComObjectRoot and family, right? Then, cannot you just provide a suitable InternalRelease implementation and forget about specializing?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
CMyCOM is derived from CComObjectRoot family.
i can overwrite InternalRelease but it cann't help.
Here is the code of CComObject::Release:
STDMETHOD_(ULONG, Release)()
{
ULONG l = InternalRelease();
if (l == 0)
delete this;
return l;
}
CComObject::Release method decides whether to delete the object or not.
Therefore, overwriting InternalRelease can't help.
So what else can i do?
|
|
|
|
|
Maybe you can return a non-zero value from InternalRelease, as the life-tracking of your objects is handled internally.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I thought about that, but the CComObject::Release should return the object to the pool instead of deleting it.
CComObject::Release should check if the reference counter is 1 then the object should be returned to the pool. (Intead of deleting it when the counter is 0).
Therefore, i must change CComObject::Release implementation.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
