[Libreoffice] [PATCH] ScGlobal::GetAutoFormat not always required to create fresh instance
Stephan Bergmann
sbergman at redhat.com
Wed Jan 11 04:14:26 PST 2012
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
More information about the LibreOffice
mailing list