>David,
>
>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" )
>

Actually, I think the problem is dynamic resolution - the same problem as calling a procedure from a procedure file; the context "thisform" is neutral - you aren't "in scope" to a form at the time the code executes, perhaps there is no _VFP.ActiveForm, or it resolves thisform differently at different times. It's the same problem encountered when doing something like an OKL, like ON KEY F8 =thisform.SomeMethod().

Using SET FILTER, you need to resolve the form reference to a literal of the correct type to prevent the fiter expression from going out of scope as you pointed out below.

>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
>
>>Wouldn't be surprised if there has been some general discussion about this issue in the past. I'd appreciate a pointer to a broader discussion of the issue I raise here.
>>
>>I just discovered that using a 'thisform' reference in a filter condition is very unhealthy and also that the COUNT function doesn't know what to do with property names having implied references (inside a WITH...ENDWITH block).
>>
>>The following code generated an unknown member error.
>>

>>WITH thisform
>>
>>COUNT FOR logicfuncof(.myproperty) TO nmycnt
>>
>>ENDWITH
>>

>>
>>OK, fine. I explicitly made the reference be thisform.myproperty and the error went away. But then I even got a wierder error.
>>
>>The now corrected code still produced an unknown member error....but for a property which was not even in the current form! Ohhhhhhhhhhhh!
>>
>>In myform1 I do:
>>

>>SET FILTER TO logicfuncXtof(thisform.otherproperty)
>>

>>
>>Then I fire up modal myform2 which executes the COUNT command above, and the COUNT command results in an 'otherproperty' unknown member error.
>>
>>I guess this is because:
>>
>>(1) filter expressions are stored as character strings
>>(2) functions like COUNT use an implicit conjuction of the FOR clause with the current filter expression. So, my COUNT statement above really executes:
>>

>>COUNT FOR logicfuncof(.myproperty).AND.logicfuncXof(thisform.otherproperty) TO nmycnt
>>

>>
>>I feel lucky that the form that executes the COUNT does not have a property with the same name as the one calling it, cause I'm pretty sure the 'thisform' in the implied conjunction would have been happy as a clam to use it without complaining.
>>
>>This bodes badly for saving and restoring filter context, unless I steer clear of 'this' and 'thisform' in filter expressions.
>>
>>Any insight on this 'feature' of VFP would be greatly appreciated.