Hi Muthu, On Tuesday, 2012-06-19 09:41:08 +0530, Muthu Subramanian K wrote:
This doesn't seem to be a problem on 3.6+,
Maybe the boost::ptr_vector::sort() used there happens to be stable, I'm not sure at the moment if it really is.
so we need this workaround only on <=3.5. May be we can live that? If so, it would be nice to commit this to the 3.5 branch, please? That said, there could still be cases (in any version) that the order is changed by sort() (may be some corner cases). Though insert takes care of keeping the array sorted (and the order of the attribs as well).
Other functions where CharAttribList::ResortAttribs() is called seem to not guarantee that. So your fix would only help where the entire array is already sorted, not where only partial sorting is to be retained. Would be good to know if ContentNode::ExpandAttribs() and ContentNode::CollapsAttribs() and EditDoc::InsertAttribInSelection() and EditDoc::RemoveAttribs() really work as expected in these cases. Could you please check? Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
Attachment:
pgpwuNSGC5nQS.pgp
Description: PGP signature