On Tue, 2011-09-20 at 22:10 +0400, Ivan Timofeev wrote: > 2011/9/20 Caolán McNamara <caol...@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. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
