Ed,

I've had problems in the past using thisform.Property as a view parameter even when the only place a view is USEd or Requery()'d inside a method of that form. Almost like a separate execution thread where thisform goes out of scope, but a LOCAL memvar created right before the USE/REQUERY() does not fail.

It's quite easy for OKLs to fire out of scope of a form method so thisform can't be used, and _screen.ActiveForm must be tested for validity before being used. For the lurkers OKLs for forms should be replaced by code in the form.KeyPreview() event.

>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