Aron Budea <> changed:

           What    |Removed                     |Added
                 CC|                            |

--- Comment #8 from Aron Budea <> ---
Eike, here are my thoughts on this bug, but the big picture is still unclear,
can you please advise on how to approach it?

The immediate cause of this is that when exporting the built-in defined range,
it takes Excel's limits for colummns, which is 16384...
// *** 2) print titles *** ----------------------------------------

...then later, when XclExpNameManagerImpl::CreateName(...) is called, it checks
for an existing built-in range name, but also tries to match the range, which
is still 1024 here, so they won't match.
If the two matched, then as far as I can see, it would update the built-in
range based on the defined one. However, first it checks if the two token
arrays match... when could this work sensibly?
/*  Try to replace by existing built-in name - complete token array is
        needed for comparison, and due to the recursion problem above this
        cannot be done earlier. If a built-in name is found, the created NAME
        record for this name and all following records in the list must be
        deleted, otherwise they may contain wrong name list indexes. */
sal_uInt16 nBuiltInIdx = FindBuiltInNameIdx( rName, *xTokArr );

It's not clear to me why the built-in named ranges are gathered both directly
from the respective spreadsheet settings, and also from regular named ranges
(as imported). Would it make sense to either only match based on names, or even
do away with the double handling of built-in names?

And indeed, when revisiting bug 112571 after its fix, as soon as the user
updates the print ranges, those names are duplicated again because of the
double handling and range-checking.

You are receiving this mail because:
You are the assignee for the bug.
Libreoffice-bugs mailing list

Reply via email to