> Sorry, I totally disagree on the "easier to read" part.
> Template syntax is a nightmare!
Well, it doesn't seem like that to me, but it's a matter of taste really, so
I can't flame you here. :-)
But what I meant by my comment was not about templates. It was about the
fact that you implement all your COM methods in one place (rather than
having a zillion of nested classes), you list all your supported interfaces
in one place, you use the default implementation of interfaces in an
intuitive way, the implementation of IUnknown is clearly separated from your
code implementation and can easily be switched, and stuff like that...
> 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)
I like this way of thinking. Let us know if you need help.
> 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.
See, HRESULT is a typedef for long. So on the VC COM server side, a long
return value is the same as HRESULT.
Now, on the VC COM client side, the COM wrapper genrated by #import uses the
SUCCEEDED macro to test the method call, and if it's successful, it return
S_OK. So if your long return value is positive, that piece returns S_OK.
On the VB COM client side, VB runtime checks the return HRESULT (long)
value, and if it indicates success (is positive) then no error gets
reported.
I hope this correctly deciphers what happened. If not, let me know.
> 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!).
You may want to check out the .tli file created by the compiler. A line of
code helps more than 1,000 lines of description!
> Whoa - how can VB see the method /return/ that value when the method
> /requires/ it as a parameter, not returns it?
Look at the IDL again; there is an [out,retval] attribute before the
parameter to MyMethod( ). This gets mapped to the method return value in
VB. In fact, VB can't access HRESULT return values directly. All it can
handle are HRESULT errors using On Error statement.
Nice COM magic, isn't 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?
Generally, it's not a good idea to return anything except than an HRESULT
from a COM method. Don't try it, you will be bitten.
-------------
Ehsan Akhgari
Farda Technology (www.farda-tech.com)
List Owner: [EMAIL PROTECTED]
[ Email: [EMAIL PROTECTED] ]
[ WWW: http://www.beginthread.com/Ehsan ]
Cold silence has a tendency to atrophy any sense of compassion...
