[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