>>>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.
Difference in opinions hath cost many millions of lives: for instance, whether flesh be bread, or bread be flesh; whether whistling be a vice or a virtue; whether it be better to kiss a post, or throw it into the fire... (from Gulliver's Travels)