We managed to replicate the issue on a PC using Windows XP Pro SP2, OpenOffice
Build 1.9.125 language English, and MAC OS 10.3, OpenOffice build 1.1.2 and Neo
Office /j 1.1

We managed to replicate your issue.

Test Instructions

1)	Open a new OpenOffice spreadsheet (Calc)
2)	Input “Test†into A1
3)	Input values 1-14 into A2:A15
4)	Select A1:A15
5)	From top menu select Data->Filter->AutoFilter
6)	Click on the arrow on the right side of A1 and selected top 10
7)	Rows 2-5 become hidden (this is expected behavior), the arrow on the right
side of A1 changes color to blue (implying the filter is active)
8)	Click on the arrow on the right side of A1 
9)	The arrow changes to the color black
10)	Press ESC
11)	The filter is still active
12)	The arrow stays black (which to our understanding means that the filter is
not active), when it should have changed back to blue (or never changed to black
in step 8)

Additional testing:

13)	Save the document (with the arrow as black but with filter active)
14)	Close Calc
15)	Open saved file
16)	Now the arrow is colored blue (distinguishing the filter as active)

Our additional testing showed a workaround for the problem.
Save and load the spreadsheet and the actively filtered columns will be
correctly colored.

This issue may create some confusion to the user, on whether or not the filter
is active but for all intensive purposes this issue is not critical, but should
be fixed to clarify the user interface. 


Steve Wu and Jacek Leowski

Created attachment 29315 [details]
Test case

Hi Niklas,

one for you I think.

Frank

This bug you will find in V2.0 too.

*** Issue 67395 has been marked as a duplicate of this issue. ***

It would be great to have this bug targeted to OOo 2.x.

Created attachment 47997 [details]
53533.patch

Invalidating the whole window is a bit extreme. It's unnecessary to paint so
much, and the button will still be visible black for a short while.

Either draw the button with the right state (see
ScGridWindow::HandleMouseButtonDown), or invalidate only the button area, but
then instead of drawing it directly.

Created attachment 48036 [details]
53533(2).patch

Created attachment 49174 [details]
issue 53533.patch

That would add a coplete repaint to every ReleaseMouse call for any window.
That's worse than the first patch.

The following has nothing to do with this issue, but it is about the same
problem: Missing/bad indication if filter is applied: Issue 66663

Created attachment 49304 [details]
issue 53533(4).patch

1. The last patch doesn't apply to recent versions (2.3 or newer).
2. Again, it introduces repaints in unrelated situations.

If Invalidate is used, it should be only in those cases where
"aComboButton.Draw( FALSE )" was called before, and only for the pixel area of
the button.

Created attachment 49512 [details]
issue 53533(5).patch

Drawing the button with the right flags is good, but using the position from the
mouse event doesn't work if the mouse was moved between the button-down and
button-up event. The position should be taken from pFilterBox instead.

Created attachment 49544 [details]
issue 53533(6).patch

I meant ScFilterListBox stored column and row position. GetPosPixel is always
(0,0), the position within the floating window.

Created attachment 49587 [details]
issue 53533(7).patch

The last patch is good and is now in CWS "calc45" (gridwin.cxx 1.85.4.2).

*** Issue 83980 has been marked as a duplicate of this issue. ***

back to QA for verification

found fixed on cws calc45 using Solaris, Linux and Windows build

found integrated on master OOHm5 using Solaris, Linux and Windows builds

*** Issue 88353 has been marked as a duplicate of this issue. ***