Re: [Libreoffice] [PUSHED][PATCH][REVIEW 3-4] Fix for fdo#38391

On Tue, 2011-09-20 at 22:10 +0400, Ivan Timofeev wrote:
> 2011/9/20 Caolán McNamara <caolanm@redhat.com>:
> > Hmm, if in normal mode I type in 3-4 I get that range previewed, change
> > it to "foobar" and it stays previewing 3-4, which isn't great either
> > really.
>
> In normal layout in Writer and in any modes in other apps, i.e.
> brochure layout in Writer is the only dissimilar place. I think that
> ideally there must be a filter that keeps the "Range" field out of
> incorrect input according to context... 

yeah, 

a) for normal print mode at core/sw/source/core/doc/doc.cxx in
SwDoc::CalculatePagesForPrinting we call
StringRangeEnumerator::getRangesFromString without clearing the
o_rPageVector argument, so if someone has typed 5-6 and then types .
then when aEnum.setRange returns false with e.g. "5-6." the old valid
"5-6" range result remains in the vector so what pages were previously
selected remain unchanged when the range text becomes invalid.

b) while for brochure print mode at core/sw/source/core/doc/doc.cxx in
SwDoc::CalculatePagePairsForProspectPrinting we call
StringRangeEnumerator::getRangesFromString with an empty o_rPageVector
argument and we've already cleared rPagePairs, which gets filled from
the page vector argument, so the prior page selection has been thrown
away.

Indeed, moving the code to clear rPagePairs below the call to
StringRangeEnumerator::getRangesFromString in b would indeed make it
work like a.

mode a is probably prone to nasties though, e.g. we may get different
results between typing an invalid range in (e.g. "1-5.") vs pasting it
in, seeing as when typing "1-5." "1-5" will be seen before . is typed.
So the output will remain 1-5 when the invalid "1-5." is later seen. If
pasted in however we may see "1-5." straight away, and so retain the
range value seen before the paste started.

So I reckon we might be better off modifying
StringRangeEnumerator::getRangesFromString to always clear its page
vector argument, and then its probably worth being more forgiving and
output what valid ranges in the text can be extracted before the
invalid chars are seen.

So "1-5junk" ends up always equivalent to 1-5 (if the return code is
ignored) and "junk" is equivalent to 0.

> But what about of my original patch for now?

What do you think about
http://cgit.freedesktop.org/libreoffice/core/commit/?id=5a0e780d8a4194c812f436a2362098202fcfa29e
?, does that make things consistent without any obvious problems ?

C.