On 01/06/2012 07:03 PM, Stephan Bergmann wrote:
So, I would appreciate it if some Calc aficionado could look at the
patch, whether it actually makes any sense. It would be crucial to look
at the remaining calls to ScGlobal::GetAutoFormat, in
sc/source/core/data/table4.cxx
sc/source/ui/docshell/docfunc.cxx
sc/source/ui/unoobj/afmtuno.cxx
sc/source/ui/unoobj/cellsuno.cxx
and check whether not creating a fresh ScAutoFormat is OK for them, or
whether they should be calls to GetOrCreateAutoFormat after all (and the
confusing null-checks removed).
Thanks for the feedback, guys. I decided to pushed that now, with
further modifications, as
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=0e4b36269097f8865bdbc1b9d299a2776ae0cc06>.
I inspected all the remaining calls to GetAutoFormat, and all (except
the one in ~ScAutoFormatObj) call GetCount and/or operator[] on the
returned ScAutoFormat, and since the ScAutoFormat ctor calls Insert to
add at least one element, code calling GetCount or operator[] does
behave differently for
p = ScGlobal::GetOrCreateAutoFormat();
... p->GetCount() ...
than for
p = ScGlobal::GetAutoFormat();
if (p) { ... p->GetCount() ...
So I changed them to call GetOrCreateAutoFormat now. (So, as we end up
with one call to GetAutoFormat only, I could also have switched to
Kohei's HasAutoFormat suggestion. But I had to modify all the other
places anyway, removing the redundant null-checks.)
Markus' more ambitious (but most certainly even better, in terms of
ultimate correctness) ideas about ScAutoFormatObj - ScModel - ScGlobal
lifecycle remain as-of-yet unaddressed.
Stephan
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
