sw user field type: fix locale of string -> float conversion
The key part is the SwUserFieldType::GetValue() hunk, the field type has
to always use the same locale, which means if we get an SwCalc reference
that works with the document or field locale that has to be switched
temporarily.
tdf#113686 sw: handle sections when counting height of first content line
When moving back a row that has a single text frame, it should not
matter if that text frame is in a section frame or not.
The problem was that the bugdoc has a split (outer) table, the follow's
ShouldBwdMoved() returned false, as
SwTabFrame::CalcHeightOfFirstContentLine() returned USHRT_MAX, as it had
no idea how to calc the height of a text frame in a section frame.
Fix this by looking "through" the section frame, and handling "text
frame" and "text frame in section frame" the same way.
tdf#113520 sw split sections in tables: avoid empty page after content del
The problem was that since split sections are allowed in nested tables,
deleting enough content so that the full content of a page is removed
results in an empty page, having only a 0 height table. I.e. the split
section gets removed properly, the inner table (and its row and column)
as well, but the outer table is still there, though it is marked to have
0 height.
This results in a situation that the previous page doesn't have free
space (the in-table section tries to take as much space as it can), but
on the other hand we try (and fail) to move the 0 height table on the
current page to the previous one, as it doesn't have free space. At the
end the "empty" page still has an invisible table frame, so it is not
removed.
Fix the problem by allowing the move of a 0 height follow table frame
from the current page to the previous one, even it has no empty space.
tdf#113445 sw: avoid hitting loop control with a dozen of in-table sections
The bugdoc has an (outer) table containing a single cell, which has an
(inner) table with 12 cells, all content is inside sections, one section
/ cell.
This relatively simple setup can already hit the loop control in
lcl_RecalcRow(), as the SwLayNotify dtor always does invalidation in an
async way, so the loop control's counter is incremented after each and
every table cell.
Instead of increasing the max tolerance in lcl_RecalcRow() (one can
easily construct a document where the bug is still there even if the max
is set to 100 instead of the current 10 iterations), just calculate the
lower synchronously.
tdf#113287 sw split sections in tables: fix missing invalidation on sect del
The problem was that the Table1:A2 cell contents was wrapped in a
section that was first split, then all the contents was moved to the
next page, finally the empty master was also moved to the next page. At
this point the master had 0 height, and when it was removed, the follow
section frame had invalid positions, including all of its contents.
Position invalidation for table contents works by first invalidating the
table frame position, which triggers an invalidation chain for both all
next frames and the lower frame. Other lower frames are not invalidated,
that happens when the first lower is calculated, in
SwLayoutFrame::MakeAll(), when the SwLayNotify dtor is executed. This
mechanism did not help us here, as the master section frame was already
marked for deletion, so SwLayoutFrame::MakeAll() was not called for it,
so neither of its next frames were re-positioned.
Fix the bug by explicitly invalidating the position of the next frame in
SwSectionFrame::MakeAll(), for the "return early, this section will be
deleted anyway" case. (The alternative could be to watch out for
0-height sections in the SwLayNotify dtor, but the problem is specific
to section frames, so SwSectionFrame is probably a more expected place
for this change.)
tdf#113153 sw: fix layout loop with split in-table sections
The problem was in SwFrame::GetNextSctLeaf(): it called WrongPageDesc()
to find out if pLayLeaf is a container that is on an acceptable page,
but it was too aggressive, and discarded a split table cell that was in
a follow table (so later it'll be moved to a next page), but on the same
page.
The result was that a new page was created, but later in
::doInsertPage() we noticed this unnecessary page and removed it. The
effect of that was that the in-progress layout action's m_bIsAgain flag
was set to true, restart the layout again and again.
Given that in-table split sections never need to create a new page frame
for the follow section (the cell does this for us already), just don't
discard pLayLeaf when WrongPageDesc() finds it and we're in the split
section-in-table case.