On 2017-05-08 16:45, Fred Taylor wrote:

You have to move the record pointer to get the filter to "kick in". You might try SKIP 1 IN yourtable and SKIP -1 IN your table and see if you come back to the same record # you started at.

Fred

Hi Fred (and Richard!),

That sounds like a workable plan. It'd help if I had a Key field but I don't; still, RECNO('myCursor') should suffice and tracking my spot and verifying if it was affected.

Thanks!

On 2017-05-08 16:50, Richard Kaye wrote:

Yep. Store the recno to a memvar before you set the filter. GO memvar. Check for EOF. You'll probably want to set lockscreen while you're doing all that stuff.

Good tip about the LOCKSCREEN.

Then I think Mike's on the right path, wrapping any GO command in a try..catch.

--

rk

-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Fred Taylor Sent: Monday, May 08, 2017 5:26 PM To: profoxtech@leafe.com Subject: Re: Question about determining when record not showing after filter applied

GO recordno does not honor the filter. You can still go to a filtered record (or deleted).

Fred

On Mon, May 8, 2017 at 1:50 PM, Richard Kaye rkaye@invaluable.com wrote:

Yep. Store the recno to a memvar before you set the filter. GO memvar. Check for EOF. You'll probably want to set lockscreen while you're doing all that stuff.

--

rk

-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of mbsoftwaresolutions@mbsoftwaresolutions.com Sent: Monday, May 08, 2017 4:49 PM To: profoxtech@leafe.com Subject: Re: Question about determining when record not showing after filter applied

On 2017-05-08 16:45, Fred Taylor wrote:

...

You have to move the record pointer to get the filter to "kick in". You might try SKIP 1 IN yourtable and SKIP -1 IN your table and see if you come back to the same record # you started at.

Fred

Hi Fred (and Richard!),

That sounds like a workable plan. It'd help if I had a Key field but I don't; still, RECNO('myCursor') should suffice and tracking my spot and verifying if it was affected.

Thanks!

[excessive quoting removed by server]

On 2017-05-08 16:52, John Weller wrote:

Could you not check to see if the filter applies to the current record? That is if filter is applied to myfield = .t. Then is myfield = .f.

Too many conditions on the filtering clause to make this approach likeable.

On 2017-05-08 16:49, Ted Roche wrote:

See what GO (RECNO()) does.

"Record is out of range" error. I suppose I'll just put a TRY/CATCH around it and in the CATCH put a GO TOP. (These recordsets are a handful of records, so not concerned about any penalty about GO TOP vs. LOCATE.)

Sorry Mike,

it is better to use filter() instead of set("FILTER") because the latter trows Error 18 - Line is too long if the filter expression is long more than 255 characters.

Gianni

On Tue, 09 May 2017 01:00:35 +0200, Gianni Turri giannit62@gmail.com wrote:

Hi Mike,

I'm doing in this way:

if ! eval(set("FILTER")) locate rest endif

Gianni

On Mon, 08 May 2017 16:39:21 -0400, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:

VFP9SP2

After applying a filter to a grid cursor, I want to know if the current record pointer (not moved since the filter applied) is on a record that is affected by the filter? That is, if the record pointer is on a record that is no longer visible due to the filter, I want to reset the pointer to the first record in the cursor, or perhaps the previous or next record that IS showing yet even after the filter applied.

My testing shows that my current record pointer does not move after the filter applied (as expected) and EOF('myCursor') is .F. (which is technically true, since it's on a valid record, although it's being filtered out).

Ideas? tia! --Mike

On 2017-05-09 06:36, Alan Bourke wrote:

IMO the best approach is to use autoinc id columns in tables with a primary or candidate key instead of relying on the record number, and base grids etc on cursors with the relevant subset of data instead of using filters.

Well sure but when working inside somebody else's framework, you can't always get what you want...you get what you neeeeeeeed. (Think Rolling Stones song.)