<div class="gmail_quote">On Wed, Jan 11, 2012 at 3:39 PM, Keith McRae <<a href="mailto:keithcoder@gmail.com">keithcoder@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hello all I've hacked the tools/inc/stream.hxx and tools/source/stream/stream.cxx to remove operator >>(long&) and operator <<(long). To make tools/ build correctly I've also had to hack: tools/source/generic/fract.cxx tools/source/generic/gen.cxx tools/source/generic/poly.cxx SvStream& operator << ( SvStream& rOStream, const Fraction& rFract ) SvStream& operator >> ( SvStream& rIStream, Fraction& rFract ) SvStream& operator>>( SvStream& rIStream, Pair& rPair ) SvStream& operator<<( SvStream& rOStream, const Pair& rPair ) SvStream& operator>>( SvStream& rIStream, Polygon& rPoly ) SvStream& operator<<( SvStream& rOStream, const Polygon& rPoly ) so that these operators (de)serialize the Fraction, Pair and Polygon members (declared as long) as sal_Int32. Trying a full build resulted in "undefined reference to SvStream::operator>>(long&)" in svl/ vcl/ and svtools/ (so far). As most of these errors are the result of trying to (de)serialize Pair derived classes, I'm now wondering whether it may be a good idea to change the troublesome members of these classes to sal_ types? Best regards Keith </blockquote><div> A quick hack and attempt at build tells me that would be a complete nightmare! I'll leave that until I'm more familiar with the code :-) </div></div>