On Nov 12, 2010, at 11:44 AM, Paul McNett wrote:
> Just so I'm clear, I think the proper behavior would be:
>
> 1) unfiltered dataset RowCount of 2
> 2) filter() called; RowCount of 1
> 3) new() called; new record added to the filtered dataset even though it may
> not
> match the filter.
> 4) RowCount of 2
> 5) removeFilter[s](); RowCount of 3
I'm just catching up on things after returning home last night, so
forgive me if I missed anything.
I see the problem with the call to new() deleting the original
unfiltered data set; it's creating a new dDataSet instance (since tuples are
immutable), which loses the information about the filter stack. That's a
straightforward fix.
But I'm wondering about step #5 above: the filter()/removeFilter()
works via a LIFO stack. removeFilter() simply pops the last entry on the stack
into the cursor's current dataset. In your scenario, that entry would not
contain the record added to the filtered dataset. Similarly, if you were to
delete records in the filtered dataset, when you call removeFilter(), it will
pop the last dataset, which will contain the now deleted records. If you modify
records in the filtered dataset and then removeFilter(), those changes are
gone. This is more or less expected behavior, since the advantage of filter()
is that doesn't touch the database.
Filtered datasets were envisioned primarily for limiting displayed
data. If you need to be modifying data and have that modified data continuously
updated as filters are added/removed, you should probably be doing standard
requery() calls instead of filter() calls.
-- Ed Leafe
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
Searchable Archives: http://leafe.com/archives/search/dabo-dev
This message:
http://leafe.com/archives/byMID/[email protected]
