> 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.


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).

My approach in this sort of situation is to try and externalise the
management code. That is;

I would use my own first/next/insert/edit buttons on the form (not
the buttons that come on TIB_UpdateBar etc). This allows me to
attach code before and after the various dataset processing that
needs to take place, and to control if and when it happens.

hth

--
Geoff Worboys
Telesis Computing