Hi,
I have implemented a "quick and dirty" fix for the problem below.
Mainly the problem is the missing indirect type creation in unpackType in
urp_unmarshal.cxx:
at the end of unpackType:
if( ! pTypeRef )
{
pTypeRef = * typelib_static_type_getByTypeClass(typelib_TypeClas
s_VOID);
typelib_typedescriptionreference_acquire( pTypeRef );
}
// MISSING HANDLING FOR SEQUENCE
else
{
switch (nTypeClass & 0x7f) {
case typelib_TypeClass_SEQUENCE:
typelib_TypeDescriptionReference *pIndirectTypeRef =
NULL;
typelib_typedescriptionreference_acquire( pTypeRef );
typelib_static_sequence_type_init(&pIndirectTypeRef,
pTypeRef);
typelib_typedescriptionreference_acquire(
pIndirectTypeRef );
pTypeRef = pIndirectTypeRef;
break;
}
}
// MISSING HANDLING FOR SEQUENCE END
// pTypeRef is already acquired
*(typelib_TypeDescriptionReference**)pDest = pTypeRef;
return bReturn;
}
and in unpack "case typelib_TypeClass_ANY:" there must be some code added for
unpacking of 0 ..n sequence members after returning from unpackType.
If you are interested in more details, please let me know.
Arnulf
Am Freitag, 2. September 2005 11:55 schrieb Arnulf Wiedemann:
> Hi Stephan,
> Am Freitag, 2. September 2005 10:52 schrieb Stephan Bergmann:
> thanks for the answer.
>
> > Arnulf Wiedemann wrote:
> > > Hi,
> > > I am trying to use the XInvocation invoke function and generating
> > > directly the urp protocol input to be read from a ooo server started
> > > listening on the urp protocoll socket. This is working correctly for
> > > some calls, but there is a problem using the XComponentLoader
> > > loadComponentFromURL method.
> > >
> > > invoke expects for the aParams Parameter a sequence<any>
> > >
> > > That works ok for the first three arguments of loadComponentFromURL:
> > > URL string -> TypeClass STRING and a compressed String
> > > TargetFrameName -> TypeClass STRING and a compressed String
> > > SearchFlags long -> TypeClass LONG and a long value
> > > Arguments -> ??? (I am trying: TypeClass SEQUENCE and the
> > > type_cache_index for ::com::sun::star::beans::PropertyValue followed by
> > > the marshalled STRUCT members, with no success)
> > >
> > > How can I marshal a "sequence< ::com::sun::star::beans::PropertyValue
> > > >" ?
> > >
> > > Reading the code in source/remote/urp/urp_unmarshal.cxx:
> > >
> > > Unpacking a sequence of ANY in the OReaderThread on the server calls
> > > for every member of that sequence the method unpack for ANY. Within
> > > "case typelib_TypeClass_ANY:" method unpackType is called and for types
> > > > 14 (SEQUENCE == 20) after unpacking the nTypeClass, a typecache index
> > > is expected (file urp_unmarshal.cxx).
> > >
> > > I made that type for the typecache
> > > index ::com::sun::star::beans::PropertyValue (marshaling the
> > > appropriate nCacheIndex), and after the call to method unpackType on
> > > the server side in that case directly a
> > > ::com::sun::star::beans::PropertyValue STRUCT is expected method unpack
> > > (in file urp_unmarshal.cxx), because nCacheIndex forces the type to be
> > > ::com::sun::star::beans::PropertyValue (== STRUCT).
> > >
> > > I think that is not correct, because in the case of a SEQUENCE (within
> > > an ANY) there should be first a call to determine the size of the
> > > sequence and after have the sequence_size the elements of the sequence
> > > should be unmarshalled (in my case the
> > > ::com::sun::star::beans::PropertyValue STRUCT elements).
> > >
> > > I have tried a lot of different ways for marhsaling the Arguments
> > > parameter with no success (either with a "no conversion possible"
> > > exception or passing the code with the comment "severe error during
> > > extracting, dispose" comment).
> > >
> > > Or is there another way for marshaling the Arguments parameter on the
> > > client side?
> > >
> > > Arnulf
> >
> > A sequence of length k is represented in URP as the compressed number k
> > (see <http://udk.openoffice.org/common/man/spec/urp.html> for the
> > definition of "compressed number") followed by the URP representations
> > of the values v1, ..., vk. A quick glance at urp_unmarshal.cxx suggests
> > that the code works as intended: unpack of an ANY reads the type and for
> > type==SEQUENCE iterates to unpack a SEQUENCE, which first of all reads
> > the compressed number k.
>
> If I understand that correctly, that is not completely true:
> the unpackType called from "case typelib_TypeDescription_ANY:" unpacks the
> type class and for types > 14 (SEQUENCE == 20) it unpacks a type cache
> index and returns the type found via the type cache index. After return the
> returned type is unpacked in unpack without taking care of the sequence!
> Arnulf
>
> > -Stephan
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
