Why does svtools::EditBrowseBox::IsCursorMoveAllowed paint?

[Lionel Elie Mamane]

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.

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9bd5e75b95d7b380f9be95913c949221dc4c0d67

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 );

and

                 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.

-- 
Lionel