Board index » cppbuilder » Problems with TypeLibrary-import

Problems with TypeLibrary-import


2004-06-04 05:08:04 PM
cppbuilder21
Hello,
I have problems to work with an imported type-library.
I tried to import the "Microsoft XML, v3.0" type-library. There, I want to
work with the "ISAXXMLReader". But some methods (e. g. parseURL) are defined
with the "unsigned short" parameter
(e. g.: virtual HRESULT STDMETHODCALLTYPE parseURL(unsigned_short* pwchUrl)
= 0; )
So this leads to problems using the standard COM-functions and
helper-functions because it's alwas incompatible with types used inside COM
(OLECHAR, LPOLESTR ...)
Is there any possibility to parametrize the importing-functionality in the
way, that those parameters appear as wchar_t* or LPOLESTR so that I can
handle them as normal? (I dont't want to change the parameters manually,
besides that, I dont't know what will happen then ...)
Or are there any other solutions?
Thanks,
Uli.
 
 

Re:Problems with TypeLibrary-import

"Uli" < XXXX@XXXXX.COM >wrote in message
Quote
Is there any possibility to parametrize the importing-functionality
in the way
No.
Quote
I dont't want to change the parameters manually
Sorry, but you will have to.
Gambit
 

Re:Problems with TypeLibrary-import

Hello Uli,
I was just in that area of code today and I'm a little puzzled. The code
that outputs the C++ parameter type is table driven. Here's the table:
TypeNames: array[VT_I2..VT_LPWSTR] of string = (
'short', { VT_I2 = 2 [V][T][P][S][C] 2 byte signed
int }
'long', { VT_I4 = 3 [V][T][P][S][C] 4 byte signed
int }
'float', { VT_R4 = 4 [V][T][P][S][C] 4 byte
}
'double', { VT_R8 = 5 [V][T][P][S][C] 8 byte
}
'CURRENCY', { VT_CY = 6 [V][T][P][S][C]
}
'DATE', { VT_DATE = 7 [V][T][P][S][C]
}
'BSTR', { VT_BSTR = 8 [V][T][P][S][C] OLE Automation
string }
'LPDISPATCH', { VT_DISPATCH = 9 [V][T][P][S][C] IDispatch
}
'SCODE', { VT_ERROR = 10 [V][T] [S][C]
}
'TOLEBOOL', { VT_BOOL = 11 [V][T][P][S][C] True=-1,
False=0 }
'TVariant', { VT_VARIANT = 12 [V][T][P][S] VARIANT
}
'LPUNKNOWN', { VT_UNKNOWN = 13 [V][T] [S][C] IUnknown
}
'DECIMAL', { VT_DECIMAL = 14 [V][T] [S][C] 16 byte fixed
point }
'', { Illegal =
}
'signed_char', { VT_I1 = 16 [T] signed
}
'unsigned_char', { VT_UI1 = 17 [V][T][P][S][C] unsigned
}
'unsigned_short',{ VT_UI2 = 18 [T][P] unsigned
}
'unsigned_long', { VT_UI4 = 19 [T][P] unsigned
}
'__int64', { VT_I8 = 20 [T][P] signed 64-bit
int }
'unsigned_int64',{ VT_UI8 = 21 [T][P] unsigned 64-bit
int }
'int', { VT_INT = 22 [T] signed machine
int }
'unsigned', { VT_UINT = 23 [T] unsigned
machine int }
'void', { VT_VOID = 24 [T] C style
}
'HRESULT', { VT_HRESULT = 25 [T] Standard return
type }
'', { VT_PTR = 26 [T] pointer
}
'LPSAFEARRAY', { VT_SAFEARRAY = 27 [T] (use VT_ARRAY in
VARIANT) }
'', { VT_CARRAY = 28 [T] C style
}
'', { VT_USERDEFINED = 29 [T] user defined
type }
'LPSTR', { VT_LPSTR = 30 [T][P] null terminated
string }
'LPWSTR'); { VT_LPWSTR = 31 [T][P] wide null
terminated string }
As you can see, it's basically a lookup based on the VT_xxxx code that
describes the parameter's typedescriptor.
(i.e. TYPEDESC.vt - see
msdn.microsoft.com/library/default.asp )
I don't have that typelibrary handy right now to verify but this leads me to
believe that the parameter type was described as VT_UI2, which would call
for unsigned_short.
We've talked about making this table customizable. It's something that I'm
probably going to do. However, that may not work unless all instances of
VT_UI2 should really be mapped to wchar_t* [i.e. BSTR] ????
I'll probably run this typelibrary under a few other importers to see the
outcome....
Regards,
Bruneau.
"Uli" < XXXX@XXXXX.COM >wrote in message
Quote
Hello,

I have problems to work with an imported type-library.

I tried to import the "Microsoft XML, v3.0" type-library. There, I want to
work with the "ISAXXMLReader". But some methods (e. g. parseURL) are
defined
with the "unsigned short" parameter
(e. g.: virtual HRESULT STDMETHODCALLTYPE parseURL(unsigned_short*
pwchUrl)
= 0; )
So this leads to problems using the standard COM-functions and
helper-functions because it's alwas incompatible with types used inside
COM
(OLECHAR, LPOLESTR ...)

Is there any possibility to parametrize the importing-functionality in the
way, that those parameters appear as wchar_t* or LPOLESTR so that I can
handle them as normal? (I dont't want to change the parameters manually,
besides that, I dont't know what will happen then ...)

Or are there any other solutions?

Thanks,
Uli.


 

{smallsort}

Re:Problems with TypeLibrary-import

Hello Bruneau,
thanks for answering, althoug I don't understand that type table :)
But I will tell you (and all the others who have the same problem), that I
managed to make it run by changing "unsigned short" to "wchar_t" manually
(simply via find/replace functionality)! This method s a little
disadvantaged, because the import (*.cpp/*.h) is created automatically (as
always mentioned), that means that the files will also be overwritten
automatically when the type-library is being actualized ...
But I'm wondering about, that noone else had similar problems and that this
problem isn't well known. Althoug I suppose, that the MSXML-library is
oftenly used (as well by BCB-programmers). So:???
Regards,
Uli
"Jean-Marie Babet" < XXXX@XXXXX.COM >schrieb im Newsbeitrag
Quote
Hello Uli,

I was just in that area of code today and I'm a little puzzled. The code
that outputs the C++ parameter type is table driven. Here's the table:

[...]
Quote
Regards,

Bruneau.


"Uli" < XXXX@XXXXX.COM >wrote in message
news:40c03bf5$ XXXX@XXXXX.COM ...
>Hello,
>
>I have problems to work with an imported type-library.
>
>I tried to import the "Microsoft XML, v3.0" type-library. There, I want
to
>work with the "ISAXXMLReader". But some methods (e. g. parseURL) are
defined
>with the "unsigned short" parameter
>(e. g.: virtual HRESULT STDMETHODCALLTYPE parseURL(unsigned_short*
pwchUrl)
>= 0; )
>So this leads to problems using the standard COM-functions and
>helper-functions because it's alwas incompatible with types used inside
COM
>(OLECHAR, LPOLESTR ...)
>
>Is there any possibility to parametrize the importing-functionality in
the
>way, that those parameters appear as wchar_t* or LPOLESTR so that I can
>handle them as normal? (I dont't want to change the parameters manually,
>besides that, I dont't know what will happen then ...)
>
>Or are there any other solutions?
>
>Thanks,
>Uli.
>
>