Eric Handbury wrote:

>
> --- In IBObjects@y..., "Jason Wharton" <jwharton@i...> wrote:
> > Does this boil down to you wanting a distinction between an event
> for the
> > actual surety that a scroll is happening or just that it may happen?
>
> In this instance, I want a before/after event which fires only on a
> row change. That row change may be a result of a grid operation, or a
> NavigatorBar operation, or an Insert that has been cancelled, etc.
> But these are all 'real' row changes initiated by 'user' operations.
> Overall, with all events, I would want a separation between what
> IBO must do internally from its published interface.
>
> > I'm confident there will not be any fundamental changes in this
> part of IBO,
> > but I would consider adding in a new event that had the behavior you
> > desired.
>
> I can appreciate that you have knowledge about IBO that I will
> never possess, but I have to ask... aren't the current Scroll events
> meant to do only what I ask? Why do we need a new event?
>

We don't. The BeforeScroll event should fire immediately before the dataset scrolls to
another record as a result of a change of record as observed by the end-user. (First,
Last, MoveBy, Next, Prior, Find, Locate, Search, Filter)

If it fires for any other reason then a separate parameter is required that provides the
reason for the scroll.

Currently it is indeed mostly useless and changing this particular event will most likely
affect no-one.

--
Raymond Kennington
Programming Solutions
W2W Team B