Why does svtools::EditBrowseBox::IsCursorMoveAllowed paint?

Lionel Elie Mamane lionel at mamane.lu
Tue Jul 24 08:49:41 PDT 2012

On Thu, Jul 19, 2012 at 12:39:43PM +0100, Michael Meeks wrote:

> On Wed, 2012-07-18 at 19:48 +0200, Lionel Elie Mamane wrote:

>> Has anybody any clue why svtools::EditBrowseBox::IsCursorMoveAllowed
>> needs to call rWindow.Paint()? It causes some pretty stupid behaviour
>> in base, namely:

> 	Nope - it looks rather crazy to me. (...)

>> If I apply the attached patch, things get faster in Base (the
>> procedure stops at step 4), but have I broken something else? I don't
>> really have a clue.

I have found out that it breaks the repainting of the current
record/row (in grid view, the green triangle/arrow that points to the
current row).

> 	I would be inclined to call:

>     virtual void        Invalidate( const Rectangle& rRect, sal_uInt16
> nFlags = 0 );

> 	instead of paint there - which -should- defer the rendering until
> everything has settled down :-)

Yes, same performance advantage for Base and seems it does not break
the repainting of the current row indicator. Pushed to master.


Thanks for the advice! One more question:

The Paint() call was preceded and followed by:

                 pTHIS->bPaintStatus = static_cast< sal_Bool >
                     (( GetBrowserFlags() & EBBF_HANDLE_COLUMN_TEXT ) == EBBF_HANDLE_COLUMN_TEXT );


                 pTHIS->bPaintStatus = sal_True;

respectively. Do these lines still make sense after switching to
Invalidate instead of Paint? I guess not, but in doubt I left
them. Please advise (or just remove them).

Actually, if my guess is right, we can remove the bPaintStatus data
member completely, as this code was the only one ever touching it (it
is private to the class) -> one horrible hack less.


More information about the LibreOffice mailing list