>>>>Why can't I just set m.FilterCondition to whatever I want in my code and then do SET FILTER TO &FilterCondition when I need to? The problem I seem to be having now is I can't keep a variable in scope that I define in the INIT (understand that is not supposed to work) or the LOAD (which I thought was supposed to work). By the time I get to a method in the form, m.FilterCondition is not understood to be defined.
>>>>
>>>>Sorry, I forgot to say that I decided not to use a form property and am using a variable instead. Scoping seems to be the issue right now.
>>>
>>>But in general I agree with Jim, of course. I think I already suggested to not use filters in one of my previous replies to you on the same topic.
>>
>>You did, but I am anyway. There are limitations to the form I'm working in that force me to use a filter.
>
>I would NOT recommend a filter to filter child records in a parent-child relation. That's what parameterized views are for.
>
>I WOULD recommend using a filter so that the user can add additional filter conditions. This may be complicated to program otherwise. Although, if you manage to do it with a view programmed in code, with a CursorAdaptor, or some other technology, that may be great, for speed reasons.

The filter is just for the base table displayed in the grid. When I go deeper, it is by using SQL to select from another table based on a key value in the first base table. Works well now that I'm using a cursor to hold the filter values. I am not creating a user-defined filter beyond what is needed for the finite number of conditons that are set via controls on the form.