> One serious recommendation: stay away from MFC when writing COM
> servers, and
> use ATL instead. It's easier to use, easier to read, has less bloat, has
> less unintuitive conventions, and IMO rocks!
Sorry, I totally disagree on the "easier to read" part. Template syntax is a
nightmare!
But that doesn't mean I won't have a go, just for the exercise. I just need
to wait for the next piece of inspiration that causes me to write one {;v)
> That's a common gotcha. I usually do something like:
>
> class COMInit
> {
> COMInit() { CoInitialize( NULL ); }
> ~COMInit() { CoUninitialize(); }
> } const g_init;
Interesting way of doing it.
> > The VB client handled it just fine, but for some strange reason the VC
> > client kept getting back zero - even though the server itself
> > confirmed that it was sending back non-zero.
>
> That zero meant S_OK. In fact, you should've said: for some
> strange reason,
> VB handles it just fine!
No, I meant what I said and said what I meant: the value returned (from my
method) was NOT a BOOL, it was a long - could be ANY non-zero value, and in
fact was - I return a CWinThread pointer cast to a long, hence any non-zero
(non-NULL) code means it started the thread OK.
VC seems to have ignored that return value and returned its own (even if I
had returned S_FALSE, I'm not sure VC would have passed it on!).
> // C++ declaration
> STDMETHOD(MyMethod)(VARIANT_BOOL * pVal);
>
> // VB client
> Dim MyObj As New MyClass
> Dim b As Boolean
> b = MyObj.MyMethod()
Whoa - how can VB see the method /return/ that value when the method
/requires/ it as a parameter, not returns it?
(requires meaning requires a place to put it, in this case)
The ODL file actually showed the long (not an HRESULT) being returned in the
prototype for the method - it seems pointless allowing return values other
than HRESULT if a VC client will ignore it?
--
Jason Teagle
[EMAIL PROTECTED]
