Al,

The comparing of the old values to the new values could be done generically as well as copying the new values to the old values. What wouldn't be done generically would be the creation of the objects. That would be in the one method (most likely a custom method that was called by the Load rather than the Load itself). Do your criteria controls get added to the form dynamically or do you modify the form when you add criteria? If they get added dynamically, then you could create your data objects dynamically as well. If you manually add the criteria controls, then it's just one more step to add the properties to the objects. And if that's still too much, you could get creative and add custom properties to your criteria controls that could then be read at form startup to build your data objects from and bind to. You could also use a metadata table to build all the controls and data objects dynamically. There's a bunch of ways to do it and it looks as if Naomi has given you a satisfactory answer.

HTH,
Chad

>Thanks for the feedback!
>
>OK, this looks like an implementation of idea #3. The only issue I have is that the ADDPROPERTY()s are essentially hard coded. If I'm going to do this at all I'd like it to be generic, so I don't have to worry what controls are actually in the Filter section (yeah, I know, not asking for much :)). Ultimately I'd like to be able to make a couple of method calls, something like
>

>* Before new filter process:
>.StoreFilterCriteria( .oFilterValuesNew )
>
>IF .oFilterValuesNew = .oFilterValuesOld
>  * No need to run filter process again
>
>ELSE
>  .FilterProcess( )
>  .oFilterValuesOld = .oFilterValuesNew
>
>ENDIF
>

It might be possible to include idea #2, putting all of the Filter controls in a container (and/or using a naming convention for the controls) to make .StoreFilterCriteria() generic.