On 18/05/12 10:26, Noel Power wrote:
Hi
somewhat of a containing fix ( I think there is other rework needed,
see below ) that avoids the mentioned crasher, please consider
cherry-picking to 3.5
Always ( afaict ) the code expects the index of the entry in the
(maTabs) vector to correspond a tab of the same index. However the
DeleteTab routine patched above will erase the entry for the tab but
if that tab isn't the last tab but instead some random tab in the
middle won't the order of the tabs be screwed ? We could check and
only delete an entry if it is the last entry ( and otherwise make a
null entry for the deleted tab ) but then we definitely would expect
the code should be ready to deal with such a 'hole' (representing a
sheet that no longer exists ) in the vector, that doesn't appear to be
the case. Is this how it should work ? I could rework it like that if
that is the intention, is it ?
and I forgot to mention the commit ( or actually 2 commit ids as it
appears I introduced a wae that was fixed by sb )
http://cgit.freedesktop.org/libreoffice/core/commit/?id=8b1d29bc9b00bc2730738a990023a65ab6e0219b
&
http://cgit.freedesktop.org/libreoffice/core/commit/?id=abb26f51eea0399754cc8f5b7d7a7d648d68f630
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
