Hi Kay, Am Freitag, 2. September 2005 09:26 schrieb Kay Ramme - Sun Germany - Hamburg: > Hi Arnulf, > > AFAIR a Sequence is marshaled as > > compressed number <n> # the size of the sequence > <value> * <n> # the sequences elements, where the type of value > depends on the sequences type > > > an Any is marshaled as > > Type # the type of the Any > <value> # the value of the Any, value is of type Type > > So, an Any with a Sequence looks like this > > Type = Sequence<SType> > compressed number <n> > <value> * <n> Yes, that is how I had understood the marshaling in that case, but looking into bridges/source/remote/urp/urp_unmarshal.cxx I cannot find any place where the "compressed number <n>" (the size of the sequence) is unmarshalled in case of a type Any. I think using invoke in the C++ client environment does not show the problem, because it uses a different way (have not completely checked what it does exactly) before going to send the marshaled stuff to the server. At least my debug did not come to that place using the C++ environment. I am not using the C++ libraries, because I am directly generate the marshaled binary messages. As I can use invoke for messages not containing a sequence, I think in princinple I am generating the correct code. > > URP is implemented in C++ _and_ Java. So, in case the C++ implementation > is understandable on the first glance, you might want to look at the > Java implementation (jurt/com/sun/star/lib/protocols/urp). The source of > truth is certainly the spec., to be found here > > http://udk.openoffice.org/common/man/spec/urp.html I know that (and the other) documents, but the details I need are not described there, because these are implementation details and I think there is a problem in bridges/source/remote/urp/urp_unmarshal.cxx for that special case. > > In URP, everything is predictive, that an unmarshaler does need to > temporarily store anything. > > Hope that helps > > Kay > > 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 > > > > --------------------------------------------------------------------- > > 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]
