--- In IBObjects@y..., Geoff Worboys <geoff@t...> wrote:

> > Obviously, something in the first Commit caused IBO to fire the
> > Scroll events on a subsequent Rollback. To me, this is a bug.
>
> A commit does a post-all. That is; it posts the editing customer
> dataset. This makes IBO believe that some sort of change may have
> been made to the dataset. So, when you later rollback, IBO is no
> longer certain that is has an up to date copy of the record/dataset
> and so performs a refresh - resulting a scroll event.

I have 3 points here:
1) The previous Commit was an Edit, so IBO must have the latest
data in its buffers. Hence, no refresh is necessary.
2) To me, transaction events (commit/rollback/etc.) should be
independent events. Why does IBO hold previous state information
between transaction events?
3) If IBO is unsure of its data after the Rollback, why doesn't it
do it everytime? (regardless of whether a Commit has been done
previously).

> Once again I think you are putting it together in an unpredictable
> manner. Doing this sort of thing inside dataset events, where there
> are large numbers of interactions and complications, is always going
> to be a point of trouble (IMHO).

I can't think of another way to do what I want. All I want is to
close all open child datasets if the user scrolls the main customer
grid. If you can help me with another algorithm, I'm all ears (as
Ross Perot said!).

Geoff, I really appreciate you spending the time on my problems.