Got an unknown based custom interface with a draw function that takes a 
HBITMAP as an [in]. The compiler is complaining that it cant convert 
HBITMAP to wireHBITMAP. What on earth is it and why do I need to convert 
or care?

"Phil Da Lick!" 
wrote in message
news:43db993c$0$6995$ed2619ec@ptn-nntp-reader02.plus.net
> Got an unknown based custom interface with a draw function that takes
> a HBITMAP as an [in]. The compiler is complaining that it cant convert
> HBITMAP to wireHBITMAP. What on earth is it and why do I need to
> convert or care?

wireHBITMAP is an over-the-wire representation of a bitmap, used for 
marshaling. A COM method that takes an HBITMAP and wants to be 
marshallable has to be specified as a [local]/[call_as] pair and provide 
appropriate marshalling stubs.

All of this should be invisible to the user of the interface. If it's 
not, the interface author did something wrong. Can you show the IDL 
and/or .H file definition of the interface?
-- 
With best wishes,
    Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not 
necessarily a good idea. It is hard to be sure where they are going to 
land, and it could be dangerous sitting under them as they fly 
overhead. -- RFC 1925

[
		object,
		uuid(blahblahblah),
		pointer_default(unique)
	]
	interface IMyUIObject : IUnknown
	{
		[helpstring("method CalculateSize")] HRESULT CalculateSize([in] IMyDataObj *pData, [out, retval] SIZE *pSize);
		[helpstring("method Draw")] HRESULT Draw([in] IMyDataObj *pData, [in] HBITMAP hBitmap, [out,retval] VARIANT_BOOL *pResult);
	};


IMyDataObj is a dual, dispatch derived interface defined in the same library. It's just got a load of get/put functions.


	HDC		hDc=::GetDC(m_hWnd);
	HBITMAP		bitmap=CreateCompatibleBitmap(hDc, bitmapsize.cx, bitmapsize.cy);

	if(SUCCEEDED(lpMyUIObj->raw_Draw(lpBarData, bitmap, &vtbool)) // c2664
	{
		// Do some shit
	}
	::ReleaseDC(m_hWnd, hDc);

error C2664: 'IMyUIObj::raw_Draw' : cannot convert parameter 2 from 'HBITMAP' to 'wireHBITMAP'

// This is what is in the imported lib.tlh in the debug folder of the client app:

struct __declspec(uuid(blahblahblah))
IMyUIObj : IUnknown
{
     //
     // Wrapper methods for error-handling
     //

     struct tagSIZE CalculateSize (
         struct IMyDataObj * pData );
     VARIANT_BOOL Draw (
         struct IMyDataObj * pData,
         wireHBITMAP hBitmap );

     //
     // Raw methods provided by interface
     //

       virtual HRESULT __stdcall raw_CalculateSize (
         /*[in]*/ struct IMyDataObj * pData,
         /*[out,retval]*/ struct tagSIZE * pSize ) = 0;
       virtual HRESULT __stdcall raw_Draw (
         /*[in]*/ struct IMyDataObj * pData,
         /*[in]*/ wireHBITMAP hBitmap,
         /*[out,retval]*/ VARIANT_BOOL * pResult ) = 0;
};

"Phil Da Lick!" 
wrote in message
news:43dbea34$0$82673$ed2619ec@ptn-nntp-reader03.plus.net
> [
> object,
> uuid(blahblahblah),
> pointer_default(unique)
> ]
> interface IMyUIObject : IUnknown
> {
> [helpstring("method CalculateSize")] HRESULT CalculateSize([in]
> IMyDataObj *pData, [out, retval] SIZE *pSize); [helpstring("method
> Draw")] HRESULT Draw([in] IMyDataObj *pData, [in] HBITMAP hBitmap,
> [out,retval] VARIANT_BOOL *pResult); };
> // This is what is in the imported lib.tlh in the debug folder of the
> client app:

Non automation compatible interfaces are not correctly represented in 
type libraries. There is no point even putting them there. #import does 
not handle them correctly. You need to use the .h file generated by MIDL 
from the original IDL file.
-- 
With best wishes,
    Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not 
necessarily a good idea. It is hard to be sure where they are going to 
land, and it could be dangerous sitting under them as they fly 
overhead. -- RFC 1925

Igor Tandetnik wrote:
> "Phil Da Lick!" 
> wrote in message
> news:43dbea34$0$82673$ed2619ec@ptn-nntp-reader03.plus.net
> 
>>[
>>object,
>>uuid(blahblahblah),
>>pointer_default(unique)
>>]
>>interface IMyUIObject : IUnknown
>>{
>>[helpstring("method CalculateSize")] HRESULT CalculateSize([in]
>>IMyDataObj *pData, [out, retval] SIZE *pSize); [helpstring("method
>>Draw")] HRESULT Draw([in] IMyDataObj *pData, [in] HBITMAP hBitmap,
>>[out,retval] VARIANT_BOOL *pResult); };
>>// This is what is in the imported lib.tlh in the debug folder of the
>>client app:
> 
> 
> Non automation compatible interfaces are not correctly represented in 
> type libraries. There is no point even putting them there. #import does 
> not handle them correctly. You need to use the .h file generated by MIDL 
> from the original IDL file.

OK, I've now removed the #import for the library in question, and substituted it with a #include the generated .h file in stdafx.h. I then had to 
include the _i.c genrated file for the IIDs and CLSIDs. That didn't work until i changed the properties for that item to not use precompiled headers. 
All is now well but I was wondering whether this is the "proper" approach - isn't #import the preferred method???!

"Phil Da Lick!" 
wrote in message
news:43dd142e$0$3634$ed2e19e4@ptn-nntp-reader04.plus.net
> All is now well but I was wondering whether
> this is the "proper" approach - isn't #import the preferred
> method???!

Once again - #import only works for automation compatible interfaces. If 
you need to use one that's not automation compatible, you have to do it 
the old-fashioned way.
-- 
With best wishes,
    Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not 
necessarily a good idea. It is hard to be sure where they are going to 
land, and it could be dangerous sitting under them as they fly 
overhead. -- RFC 1925

Igor Tandetnik wrote:
> "Phil Da Lick!" 
> wrote in message
> news:43dd142e$0$3634$ed2e19e4@ptn-nntp-reader04.plus.net
> 
>>All is now well but I was wondering whether
>>this is the "proper" approach - isn't #import the preferred
>>method???!
> 
> 
> Once again - #import only works for automation compatible interfaces. If 
> you need to use one that's not automation compatible, you have to do it 
> the old-fashioned way.

Once again (:)) Is what I've done the "old fashioned way"? I'm kinda new to com and am picking it up as I go along - I've not got a text book or 
anything and the M$ docs are less than useful for a beginner. I'm also new to visual studio :)

"Phil Da Lick!" 
wrote in message
news:43dd1756$0$6966$ed2619ec@ptn-nntp-reader02.plus.net
> Igor Tandetnik wrote:
>> "Phil Da Lick!" 
>> wrote in message
>> news:43dd142e$0$3634$ed2e19e4@ptn-nntp-reader04.plus.net
>>
>>> All is now well but I was wondering whether
>>> this is the "proper" approach - isn't #import the preferred
>>> method???!
>>
>>
>> Once again - #import only works for automation compatible
>> interfaces. If you need to use one that's not automation compatible,
>> you have to do it the old-fashioned way.
>
> Once again (:)) Is what I've done the "old fashioned way"?

Yes, that's the good old way - define your interface in IDL, compile 
with MIDL, use the generated .h file.

A variation on what you did is to #include an _i.c file (in exactly one 
..cpp or .c file in your project) rather than adding it to the project. 
Saves the need to muck with precompiled headers. The way you did it is 
fine, too.
-- 
With best wishes,
    Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not 
necessarily a good idea. It is hard to be sure where they are going to 
land, and it could be dangerous sitting under them as they fly 
overhead. -- RFC 1925

Igor Tandetnik wrote:
>>Once again (:)) Is what I've done the "old fashioned way"?
> 
> 
> Yes, that's the good old way - define your interface in IDL, compile 
> with MIDL, use the generated .h file.
> 
> A variation on what you did is to #include an _i.c file (in exactly one 
> .cpp or .c file in your project) rather than adding it to the project. 
> Saves the need to muck with precompiled headers. The way you did it is 
> fine, too.

Thanks.

Any reason why there isn't a more "elegant" way? #import seems elegant but why can't it handle custom interfaces?

"Phil Da Lick!" 
wrote in message
news:43dd2cf8$0$7000$ed2619ec@ptn-nntp-reader02.plus.net
> Igor Tandetnik wrote:
>>> Once again (:)) Is what I've done the "old fashioned way"?
>>
>>
>> Yes, that's the good old way - define your interface in IDL, compile
>> with MIDL, use the generated .h file.
>>
>> A variation on what you did is to #include an _i.c file (in exactly
>> one .cpp or .c file in your project) rather than adding it to the
>> project. Saves the need to muck with precompiled headers. The way
>> you did it is fine, too.
>
> Thanks.
>
> Any reason why there isn't a more "elegant" way? #import seems
> elegant but why can't it handle custom interfaces?

Because the type library internal format is not sufficiently flexible to 
represent all the details of a custom interface. Many fine details are 
inevitably lost. #import cannot restore the information that's not in 
the type library in the first place. TLB format is only designed to 
accurately represent automation interfaces.
-- 
With best wishes,
    Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not 
necessarily a good idea. It is hard to be sure where they are going to 
land, and it could be dangerous sitting under them as they fly 
overhead. -- RFC 1925

Igor Tandetnik wrote:
> "Phil Da Lick!" 
> wrote in message
> news:43dd2cf8$0$7000$ed2619ec@ptn-nntp-reader02.plus.net
> 
>>Igor Tandetnik wrote:
>>
>>>>Once again (:)) Is what I've done the "old fashioned way"?
>>>
>>>
>>>Yes, that's the good old way - define your interface in IDL, compile
>>>with MIDL, use the generated .h file.
>>>
>>>A variation on what you did is to #include an _i.c file (in exactly
>>>one .cpp or .c file in your project) rather than adding it to the
>>>project. Saves the need to muck with precompiled headers. The way
>>>you did it is fine, too.
>>
>>Thanks.
>>
>>Any reason why there isn't a more "elegant" way? #import seems
>>elegant but why can't it handle custom interfaces?
> 
> 
> Because the type library internal format is not sufficiently flexible to 
> represent all the details of a custom interface. Many fine details are 
> inevitably lost. #import cannot restore the information that's not in 
> the type library in the first place. TLB format is only designed to 
> accurately represent automation interfaces.

So #import is a essentially an add-on to allow automation compatible type libraries to be quickly re-used? It wasn't the original way of doin things.