>Nadya,
>
>this is a way to go, I thought about before, but I find it to slow.
>And to move record pointer - No No Noooooooo. I work with GRID's BEFORErowCOLCHANGE, this like to fire on reasons I dident like to think of. And there is code fired from this event ....
>
>I have a lot of easy-to-access filters controled by TriState-Check buttons on my grids and did not want to bore people more than I need.
>
>I've tried
>
>

>
>...
>*something to collect filter setting like shown by you
>
>lcAct_Alias = ALIAS()
>lcField     = FIELD(1)
>SELECT &lcField;
> FROM &lcAct_Alias;
> TO SCREEN NOCONSOLE;
> &lcWhere
>
>lnRecCount = _TALLY
>...
>

>
>but this give problems with FoxPro's "==" Operator wich is different on SET FILTER and SELECT SQL.

What's the difference? I don't suggest this method, because SQL works with data from disk, while count for works with buffered data. On the other hand, it moves record pointer, which might be dangerous too.
If you don't use buffering, SQL seems like a best approach here.
>
>I guess this will also occur with other SQL commands.
>
>Ive also tried
>

>
>...
>COPY TO Delete_Me
>*Not documented, but influenced by SET FILTER and I guess by SET ORDER
>USE Delete_Me IN 0
>lnRecCount = RECCOUNT()
>USE
>DELETE FILE Delete_Me.*
>...
>

>
>but this is also a kludge.


>
>For some actions the access is CLICK-CLICK on a CHECKBOX to reach a TRISTATE (it's simple a cycle off - on - not - off), every CLICK changes the filter, every change of filter need to be count, change of filter changes display and remember we use this close - to - assembler - language that is fast on build in commands and so slow in loops and jumps.


Too bad, there is no built-in function to count number of records in filtered view :(

>Thank you for help
>
>a nice weekend to everybody and goodbye
>Lutz

Nice weekend to you too.