Type Library problem 
Author Message
 Type Library problem

I'm creating a typelibrary importer, but I'm having trouble with reading
member function signatures, especially the return value. (not out, retval)

For instance the function QueryInterface returns a HRESULT. But when I have
a FUNCDESC struct of QueryInterface the return value type is 24 meaning
VT_VOID. VT_HRESULT is defined as 25 in multiple compilers and according to
MSDN funcdesc->elemdescFunc.tdesc.vt represents the type of the return
value. I'm testing it with the msxml4.dll typelibrary. Can somebody help?

if (SUCCEEDED(info->lpVtbl->GetFuncDesc(info, i, &fdesc)))

{

  tlGetTypeFromVarType(generic, fdesc->elemdescFunc.tdesc.vt); // vt is 24,
returns "void"

  info->lpVtbl->ReleaseFuncDesc(fdesc);

Quote:
}

tlGetTypeFromVarType checks the type like this:

if (vt == VT_HRESULT)

  wcscpy(out, L"HRESULT");

else if (vt == VT_I4)

  wcscpy(out, L"LONG");

etc.

Is this wrong then, should I mask the value against something?



Thu, 13 Oct 2005 18:55:24 GMT  
 Type Library problem


Quote:
> I'm creating a typelibrary importer, but I'm having trouble with reading
> member function signatures, especially the return value. (not out, retval)

> For instance the function QueryInterface returns a HRESULT. But when I have
> a FUNCDESC struct of QueryInterface the return value type is 24 meaning
> VT_VOID. VT_HRESULT is defined as 25 in multiple compilers and according to
> MSDN funcdesc->elemdescFunc.tdesc.vt represents the type of the return
> value. I'm testing it with the msxml4.dll typelibrary. Can somebody help?

Your question is a little confusing, due to a
language problem perhaps, so I may be answering
the wrong question here.  Be forewarned.

The type library is intended to facilitate use
of the described components where HRESULT's are
translated into exceptions (or not), and the
nominal returns, as indicated by [out,retval]
markers in the IDL, are treated as the actual
returns.  So, for example, given this view of
an interface in msxml4.dll,
  interface IXMLDOMImplementation : IDispatch {
      [id(0x0000009d)]
      HRESULT hasFeature(
                      [in] BSTR feature,
                      [in] BSTR version,
                      [out, retval] VARIANT_BOOL* hasFeature);
  };
the nominal return type is an Automation boolean
and failure HRESULT returns will be converted
into an exception.

The IUnknown functions have no nominal return
type, hence the FUNCDESC result you have seen.

Quote:
> if (SUCCEEDED(info->lpVtbl->GetFuncDesc(info, i, &fdesc)))

> {

>   tlGetTypeFromVarType(generic, fdesc->elemdescFunc.tdesc.vt); // vt is 24,
> returns "void"

>   info->lpVtbl->ReleaseFuncDesc(fdesc);

> }

> tlGetTypeFromVarType checks the type like this:

> if (vt == VT_HRESULT)

>   wcscpy(out, L"HRESULT");

> else if (vt == VT_I4)

>   wcscpy(out, L"LONG");

> etc.

> Is this wrong then, should I mask the value against something?

Yes.  No, I just think your expectation
just needs some adjustment.

--
-Larry Brasfield
(address munged, s/sn/h/ to reply)



Fri, 14 Oct 2005 01:53:16 GMT  
 Type Library problem

instance the function QueryInterface returns a > Your question is a little
confusing, due to a

Quote:
> language problem perhaps, so I may be answering
> the wrong question here.  Be forewarned.

This whole typelib thing is confusing :-)

Quote:
> The type library is intended to facilitate use
> of the described components where HRESULT's are
> translated into exceptions (or not), and the
> nominal returns, as indicated by [out,retval]
> markers in the IDL, are treated as the actual
> returns.  So, for example, given this view of
> an interface in msxml4.dll,
>   interface IXMLDOMImplementation : IDispatch {
>       [id(0x0000009d)]
>       HRESULT hasFeature(
>                       [in] BSTR feature,
>                       [in] BSTR version,
>                       [out, retval] VARIANT_BOOL* hasFeature);
>   };

What my program generates now for IXMLDOMImplementation is this:
typedef struct IXMLDOMImplementationVtbl

{

BEGIN_INTERFACE

void (STDMETHODCALLTYPE *QueryInterface)(GUID*, void**);

ULONG (STDMETHODCALLTYPE *AddRef)();

ULONG (STDMETHODCALLTYPE *Release)();

void (STDMETHODCALLTYPE *GetTypeInfoCount)(UINT*);

void (STDMETHODCALLTYPE *GetTypeInfo)(UINT, ULONG, void**);

void (STDMETHODCALLTYPE *GetIDsOfNames)(GUID*, char**, UINT, ULONG, LONG*);

void (STDMETHODCALLTYPE *Invoke)(LONG, GUID*, ULONG, USHORT, DISPPARAMS*,
VARIANT*, EXCEPINFO*, UINT*);

VARIANT_BOOL (STDMETHODCALLTYPE *hasFeature)(BSTR, BSTR);

END_INTERFACE

Quote:
} IXMLDOMImplementationVtbl;

The void return values are wrong of course

Also note hasFeature, the VARIANT_BOOL return type should be an out, retval
parameter and the actual return type HRESULT. But I can't just say "ok, this
is an IDispatch interface, all return values are HRESULT, and the
elemdescFunc types are out, retval parameters". Then Release and AddRef will
return HRESULT and have an ULONG * as out, retval. I'm rather confused,
there must be a way to differentiate between a return value and an out,
retval.



Fri, 14 Oct 2005 02:41:47 GMT  
 Type Library problem


Quote:


...
> This whole typelib thing is confusing :-)

That was my initial experience as well.

Quote:
> > The type library is intended to facilitate use
> > of the described components where HRESULT's are
> > translated into exceptions (or not), and the
> > nominal returns, as indicated by [out,retval]
> > markers in the IDL, are treated as the actual
> > returns.  So, for example, given this view of
> > an interface in msxml4.dll,
> >   interface IXMLDOMImplementation : IDispatch {
> >       [id(0x0000009d)]
> >       HRESULT hasFeature(
> >                       [in] BSTR feature,
> >                       [in] BSTR version,
> >                       [out, retval] VARIANT_BOOL* hasFeature);
> >   };

> What my program generates now for IXMLDOMImplementation is this:
> typedef struct IXMLDOMImplementationVtbl

> {

> BEGIN_INTERFACE

> void (STDMETHODCALLTYPE *QueryInterface)(GUID*, void**);

> ULONG (STDMETHODCALLTYPE *AddRef)();

> ULONG (STDMETHODCALLTYPE *Release)();

> void (STDMETHODCALLTYPE *GetTypeInfoCount)(UINT*);

> void (STDMETHODCALLTYPE *GetTypeInfo)(UINT, ULONG, void**);

> void (STDMETHODCALLTYPE *GetIDsOfNames)(GUID*, char**, UINT, ULONG, LONG*);

> void (STDMETHODCALLTYPE *Invoke)(LONG, GUID*, ULONG, USHORT, DISPPARAMS*,
> VARIANT*, EXCEPINFO*, UINT*);

> VARIANT_BOOL (STDMETHODCALLTYPE *hasFeature)(BSTR, BSTR);

> END_INTERFACE

> } IXMLDOMImplementationVtbl;

> The void return values are wrong of course

Why are they wrong?  Under the "intended to
facilitate" usage I described above, they
would be right.  (Actually, the first 7
methods are hidden from Automation clients,
which are one of the primary intended
consumers of type libraries.)

Quote:
> Also note hasFeature, the VARIANT_BOOL return type should be an out, retval
> parameter and the actual return type HRESULT. But I can't just say "ok, this
> is an IDispatch interface, all return values are HRESULT, and the
> elemdescFunc types are out, retval parameters".

The retval attribute is in the PARAMDESC
struct.  That tells you whether to treat
a given parameter as the nominal return
or not.  You should probably also hide
the IDispatch (and IUnknown) methods for
most consumers of the type library.

Quote:
> Then Release and AddRef will
> return HRESULT and have an ULONG * as out, retval.

They have no parameters marked with retval.

Quote:
> I'm rather confused, there must be a way to differentiate
> between a return value and an out, retval.

What you need to grasp is that 'retval' is
only intended to mark what I am calling
'nominal' returns.  These are returns for
clients that are exposing a simplified form
of interfaces where HRESULT's, IUnknown, and
IDispatch are suppressed, used as underlying
mechanism.  (JScript and VB, for example.)

It would help if you were to describe what
you are trying to accomplish with your type
library trawling.

--
-Larry Brasfield
(address munged, s/sn/h/ to reply)



Fri, 14 Oct 2005 03:13:31 GMT  
 Type Library problem

type library is intended to facilitate use

Quote:
> It would help if you were to describe what
> you are trying to accomplish with your type
> library trawling.

I'm creating a typelibrary importer that generates C headers for a
C-compiler.
I think I'll hardcode the IUnknown and IDispatch functions for IDispatch
interfaces.


Fri, 14 Oct 2005 04:12:16 GMT  
 Type Library problem


Quote:


> type library is intended to facilitate use
> > It would help if you were to describe what
> > you are trying to accomplish with your type
> > library trawling.

> I'm creating a typelibrary importer that generates C headers for a
> C-compiler.
> I think I'll hardcode the IUnknown and IDispatch functions for IDispatch
> interfaces.

As encouragement, I'll tell you this:
The IDispatch implementation that can
be built using CreateStdDispatch(...)
relies completely on information found
in the type library as made visible
thru the ITypeInfo interface.  The code
that lies behind CreateStdDispatch()
translates Invoke() calls to C function
calls using the ITypeInfo interface, so
you should be able to create signatures
for the same functions.

--
-Larry Brasfield
(address munged, s/sn/h/ to reply)



Fri, 14 Oct 2005 04:35:09 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. #import type library problems

2. #import/type library problem

3. MessengerAPI type library - IDispatch enum type problem

4. Problem getting Type Library to regester

5. Type Library Registration Problem

6. HELP: #import problem w/ COM type library

7. Problems with ClassWizard and VB OLE Type Libraries?

8. HELP: #import problem w/ COM type library

9. HRESULT return type turns into void when adding class from type library

10. type problems with .net types *arrgh*

11. Exposing interfaces in a type library that are infact defined in another type library.

12. How to get the type-library GUID in an attributed ATL project

 

 
Powered by phpBB® Forum Software