>I don't have the definitive answer, but I've deduced that things like parameterized views operate "outside" the environment of the form or method. This might also happen with FILTERs and COUNT etc. This has always seemed to work fine for me:
>
>local lnViewParameter
>lnViewParameter = this.nSomeProperty
>requery( "TheView" )

I haven't started using views yet, much less parameterized ones, but I'm guessing that in the above, lnVeiwParameter is some variable that's referenced in a SELECT-SQL statement that produces "TheView".

I did solve the problem by using a Query of the table to produce a temporary cursor whose records I could then count. I think this is what your getting at, right? (Not sure what you meant by operating "outside" the environment...)

>
>I don't use FILTERs anymore, but you will need to makes sure that the scope of the items in the FILTER will be available anytime the VFP needs to do something with the table. You can always use macro expansionto create a "static" filter:
>
>lcFilter = "SomeField = " + transform( this.nSomeProperty )
>set filter to &lcFilter

Yeah, now that I've gotten a little bit SELECT-SQL savvy I have been using it a lot more, but old habits die hard, so I've still got a mix. Actually, I used macro substitution a slightly different way...and it sorta worked too except for the fact that it broke because it got used (in the LOAD or INIT) before the form's named reference variable is created. I tried:

tfname=thisform.name
set filter to logicfuncof(&tfname..someproperty)

which puts the filter in scope for subordinate forms.

...I like your method better...evaluate the refs at the time the filter is created.