Apache OpenOffice (AOO) Bugzilla – Issue 20826
scrolling tooltip pain (patch)
Last modified: 2003-12-22 05:37:07 UTC
Calling EndScrollHdl(pScrollbar); knobbles nPgNum, which scuppers the logic to re-show this quickhelp only for new-pages. This is nastily painfull for people with scroll-mice actually reading the text apparently. This patch fixes the problem; may I commit (and to where) ? --- sw/source/ui/uiview/viewport.cxx 22 Aug 2003 12:01:25 -0000 1.25.160.1 +++ sw/source/ui/uiview/viewport.cxx 7 Oct 2003 09:33:04 -0000 @@ -781,6 +781,7 @@ IMPL_LINK( SwView, ScrollHdl, SwScrollba //Hier wieder auskommentieren wenn das mitscrollen nicht gewuenscht ist. // JP 21.07.00: the end scrollhandler invalidate the FN_STAT_PAGE, // so we dont must do it agin. + long nOldPge = nPgNum; EndScrollHdl(pScrollbar); Point aPos( aVisArea.TopLeft() ); @@ -801,7 +802,7 @@ IMPL_LINK( SwView, ScrollHdl, SwScrollba USHORT nPageCnt = pWrtShell->GetPageCnt(); if( nPageCnt > 1 && Help::IsQuickHelpEnabled() ) { - if( !nPgNum || nPgNum != nPhNum ) + if( !nOldPge || nOldPge != nPhNum ) { Rectangle aRect; aRect.Left() = pScrollbar->GetParent()->OutputToScreenPixel(
set target to OO1.1.1 reassigned to od
us->Michael: could you pls. explain what exactly is ment by "scrolling tooltip pain" and attach a bugdoc that shows the misbehaviour. BTW. what exactly does your patch? Thanks a lot. us->od: please refer to issue 12927 for a possible bugdoc.
The patch does something quite obvious - only throw up a new tooltip with the page number / title in it when you hit a new page. This stops a flickering / potentially massive tooltip permanantly obscuring chunks of the text as you scroll. To replicate, open any multi-page document, and use the scroll-mouse.
OD->Michael: Thanks for your provided patch. But only providing a new tooltip, if a new page is hit, isn't what the tooltip should to. The tooltip should provide the actual page number and the actual chapter. I integrate your patch in local version of SRX645/m19 and tested it: Using the mouse wheel to scroll doesn't change any behaviour - the tooltip is still flickering. Using the scrollbar and scroll via mouse by dragging and moving changes the behaviour as you described. Thus, no new tooltip is shown, if a new chapter/subchapter is hit. That's not, what we want. Sorry, because of that, I will reject your provided patch. I will submit a new issue, which will address the flickering problem.
closed
If you are not using the code, you might want to cull the redundant code in there - that _appears_ to have been designed to do precisely what it does with my patch applied. nPgNum is always zero when it gets to that branch so we simply was cycles, and confuse the code flow to add this: if (!nPgNum || nPgNum != nPhNum) - this is always going to be true. Unfortunately, I don't have a scroll-wheel to benefit from the flickering, which is a shame, the original bug was not down to flickering, but the fact that the tooltip frequently obscures the text you're trying to read.
OD->Michael: Thanks for your feedback. Yes, you're right: The code, you mentioned, seems to be redundant. But, first, we have to provide the fix and then we can re-work the code. The repaint errors of the normal text are already under investigation. This defect seems to be platform-dependent - it doesn't occur on Windows.
Removing target from invalid Issue, to reduce the statistics.