Al,

What about creating a data object similar to what would be created via a:

SCATTER NAME loData

You could do it by creating a couple of empty objects in the form load and storing it to a custom form property:

PROCEDURE Load()
    LOCAL loData

    loData = NEWOBJECT('Empty')

    ADDPROPERY(loData, 'criteriaField1', .t.)
    ADDPROPERY(loData, 'criteriaField2', DATE())

    this.oDataOld = loData

    loData = NEWOBJECT('Empty')

    ADDPROPERY(loData, 'criteriaField1', .t.)
    ADDPROPERY(loData, 'criteriaField2', DATE())

    this.oDataNew = loData
ENDPROC

Now, bind your controls to one of the objects and then you can compare the two objects, run your process, then copy the new set of values to the old object and be setup for the next query (optionally resetting certain fields you don't want to remember).

HTH,
Chad


>I've got a form that lets users create reports. The form is in two sections:
>
>1. First section lets users filter the data by a number of criteria
>2. Second section lets them specify GROUP BY and ORDER BY criteria
>
>The data being reported are text files that grow at 60MB/month, currently they total about 175MB. Importing and filtering these data takes several minutes so is therefore "expensive".
>
>It's quite common that users will specify a set of filter criteria, then generate different reports on the same data set using different GROUP BY and/or ORDER BY settings.
>
>What I want to do is avoid unnecessary re-filtering of the data if the user runs a report but has not changed the filter criteria. This means tracking the values of the filter criteria; if they haven't changed since the last report run there's no need to re-import/re-filter.
>
>Can anyone think of an elegant way to do this? What I've thought of so far:
>
>1. Individually tracking control values using form properties. This becomes a maintenance pig if more criteria are added later
>
>2. Putting the filter criteria in a Container, then looping through the container's .Controls collection. This is more generic and has promise, but what's the best way to store the "old" values?
>
>3. Somehow map filter criteria to 2 objects, one with old values, the other with new values. Then, compare the objects.
>
>At the moment the filter criteria controls are unbound so buffering/OLDVAL() etc. aren't available. However, they could be bound to a dummy table if that would be an elegant solution.