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

> > I can appreciate that. But it is extremely important that Events
> > are based on a very specific database activity and not used as
> > a 'default' handler for a broad range of database functions.
>
> I do actually agree with this statement. However I believe that the
> events you are seeing are true scroll events, from the perspective
> of the underlying buffers and row pointers etc. To hide such
> activity completely means introducing another layer of abstraction,
> with all its associated costs and overheads.

To be blunt... I'm not interested in the perspective of the
underlying buffers and row pointers etc.

The difference between our arguments is that you are seeing things
from the IBO internals-side, and I am seeing it from the IBO end-user-
side. From the internals-side, I'm sure you are right... that the
differences between the two events (data refreshs and scrolls), in
certain instances, are minimal. But from the end-user side, there is
a huge difference between the two. I, as an end-user, should not be
concerned when/how/where/etc. IBO internally refreshes its data, and
really, I don't care when it has to... I have the BufferSynchroFlags
to monitor that whole process. I am only concerned about the actions
that I need to do when the user scrolls the dataset.

This is a perfect example for what I said above... that the Scroll
events (in my application) are now unusable because its scope of
activity is too broad.
IBO must separate what it has to do internally from its end-user
interface.